I don't think this assert adds much value, and removing it and related
variables avoids an "unused variable" warning in release builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249511 91177308-0d34-0410-b5e6-96231b3b80d8
Since the `const` version of `getOperandBundle` returns a value of the
same type as the non-`const` version, the non-`const` version is
redundant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249509 91177308-0d34-0410-b5e6-96231b3b80d8
Because of the constant bus requirement, it is never legal to
use a literal constant for these instructions despite the encoding
allowing it. This was already doing the right thing, but note why.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249500 91177308-0d34-0410-b5e6-96231b3b80d8
This stops using an unknown reg class operand.
Currently build_vector selection has a broken looking check
where it tries to use a VGPR reg class and an SGPR one if it
sees an SGPR use.
With the source operand has an explicit VGPR class,
illegal copies will be inserted that SIFixSGPRCopies will take care
of normally later, which will allow removing the weird check
of build_vector users. Without this, when removed v_movrels_b32 would
still be emitted even though all of the values were only stored in
SGPRs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249494 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not sure why this would be necessary, and no tests fail with
them removed. Looking at the uses is suspect as well because
the use reg classes will likely change when the users are moved
as a result of moving this instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249493 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow us to optimize code such as:
int f(int *p) {
int x;
return p == &x;
}
as well as:
int *allocate(void);
int f() {
int x;
int *p = allocate();
return p == &x;
}
The folding can only be done under certain circumstances. Even though p and &x
cannot alias, the comparison must still return true if the pointer
representations are equal. If a user successfully generates a p that's a
correct guess for &x, comparison should return true even though p is an invalid
pointer.
This patch argues that if the address of the alloca isn't observable outside the
function, the function can act as-if the address is impossible to guess from the
outside. The tricky part is keeping the act consistent: if we fold p == &x to
false in one place, we must make sure to fold any other comparisons based on
those pointers similarly. To ensure that, we only fold when &x is involved
exactly once in comparison instructions.
Differential Revision: http://reviews.llvm.org/D13358
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249490 91177308-0d34-0410-b5e6-96231b3b80d8
This is handy for some AutoFDO stuff, and seems like a minor improvement
to correctness (otherwise a debug info consumer might think the decl
line/file of the def was the same as that of the declaration - though
what a consumer might use that for, I'm not sure - maybe "list <func>"
would've misbehaved with the old behavior?) and at a minor cost (in my
experiment, with fission, without type units, without compression, 0.01%
growth in debug info in the executable/objects, 0.02% growth in the .dwo
files).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249487 91177308-0d34-0410-b5e6-96231b3b80d8
Our current emission strategy is to emit the funclet prologue in the
CatchPad's normal destination. This is problematic because
intra-funclet control flow to the normal destination is not erroneous
and results in us reevaluating the prologue if said control flow is
taken.
Instead, use the CatchPad's location for the funclet prologue. This
correctly models our desire to have unwind edges evaluate the prologue
but edges to the normal destination result in typical control flow.
Differential Revision: http://reviews.llvm.org/D13424
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249483 91177308-0d34-0410-b5e6-96231b3b80d8
This allows modules containing aliases to be lazily jit'd. Previously these
failed with missing symbol errors because the aliases weren't cloned from the
original module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249481 91177308-0d34-0410-b5e6-96231b3b80d8
from malformed Mach-O files that caused crashes.
We recently got about 700 malformed Mach-O files which we have
been using the improve the robustness of tools that deal with reading
data from object files. These resulted in about 20 small bug fixes to
the darwin based tools.
The goal here is to also improve the robustness of llvm-objdump and
this is the first two fixes. In talking with Tim Northover the approach
we thought might be best is to:
1) Only include tests for the malformed Mach-O files that cause crashes
(not all 700+ tests).
2) The test should only contain the command line option that caused the
crash and not all the others that don’t matter.
3) There should be only one line for the FileCheck that is past the point
of the crash if possible and if possible indicates the malformation.
Again the goal is to fix crashes and not so much care about how the
printing of malformed data comes out.
Tim also suggested if we really wanted to add test cases for all 700+
malformed Mach-O files putting them in the regression tests might be
an option. But many of these do not cause crashes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249479 91177308-0d34-0410-b5e6-96231b3b80d8
No classes are specializing the symbol table traits, so no need to look
through a typedef for class API. Make a few more functions private
since only SymbolTableListTraits should be using them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249476 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing inherits from `MachineBasicBlock`, so this should have no real
functionality change. Just makes the code easier to understand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249473 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
After r249211, `getSCEV(X) == getSCEV(Y)` does not guarantee that X and
Y are related in the dominator tree, even if X is an operand to Y (I've
included a toy example in comments, and a real example as a test case).
This commit changes `SimplifyIndVar` to require a `DominatorTree`. I
don't think this is a problem because `ScalarEvolution` requires it
anyway.
Fixes PR25051.
Depends on D13459.
Reviewers: atrick, hfinkel
Subscribers: joker.eph, llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D13460
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249471 91177308-0d34-0410-b5e6-96231b3b80d8
The only specializations of `getSymTab()` were identical to the default
defined in `SymbolTableListTraits::getSymTab()`. Remove the
specializations, and stop treating it like a configuration point. Just
to be sure no one else accesses this, make it private.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249469 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We currently ignore the calling convention, so there is no real reason to
assert on the calling convention of functions.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13367
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249468 91177308-0d34-0410-b5e6-96231b3b80d8
Factor out some common code used to get+set function prefix/prologue
data. This may come in handy if we ever decide to store personality
functions in the same way we store prefix/prologue data.
Differential Revision: http://reviews.llvm.org/D13120
Reviewed-by: bogner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249460 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Assign one state number per handler/funclet, tracking parent state,
handler type, and catch type token.
State numbers are arranged such that ancestors have lower state numbers
than their descendants.
Reviewers: majnemer, andrew.w.kaylor, rnk
Subscribers: pgavlin, AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D13450
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249457 91177308-0d34-0410-b5e6-96231b3b80d8
This is a cleaned up patch from the one written by John Regehr based on the findings of the Souper superoptimizer.
When writing tests, I was surprised to find that instsimplify apparently doesn't know how to collapse bit test sequences based purely on known bits. This required me to split my tests across both instsimplify and instcombine.
Differential Revision: http://reviews.llvm.org/D13250
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249453 91177308-0d34-0410-b5e6-96231b3b80d8
As mentioned in the bug, I'd missed the presence of a getScalarType in the caller of the new implies method. As a result, when we ended up with a implication over two vectors, we'd trip an assert and crash.
Differential Revision: http://reviews.llvm.org/D13441
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249442 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch, clang -O3 optimizes correctly providing > 1000x speedup on this artificial benchmark):
for (a=0; a<n; a++)
for (b=0; b<n; b++)
for (c=0; c<n; c++)
for (d=0; d<n; d++)
for (e=0; e<n; e++)
for (f=0; f<n; f++)
x++;
From test-suite/SingleSource/Benchmarks/Shootout/nestedloop.c
Reviewers: sanjoyd
Differential Revision: http://reviews.llvm.org/D13390
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249431 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The assembly printing of these is still missing the encoding size
suffix, but this will be fixed in a later commit.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13436
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249424 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes 7 tests during fast LLVM test-suite run:
* MultiSource/Benchmarks/McCat/18-imp/imp
* MultiSource/Applications/oggenc/oggenc
* MultiSource/Benchmarks/MallocBench/gs/gs
* MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
* MultiSource/Benchmarks/VersaBench/beamformer/beamformer
* MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame
* MultiSource/Benchmarks/Bullet/bullet
Error message was in the form of:
fatal error: error in backend: Cannot select: 0x95c3288: f32 = fsqrt 0x95c0190 [ORD=9] [ID=18]
0x95c0190: f32 = fadd 0x95bef30, 0x95c4d00 [ORD=8] [ID=17]
0x95bef30: f32 = fmul 0x95c4988, 0x95c4988 [ORD=5] [ID=16]
...
There was problem with selecting sqrt instruction in LLVM backend.
To fix the issue changes are made in TableGen definition for sqrt instruction in MipsInstrFPU.td and new test file sqrt.ll is added to LLVM regression tests.
Patch by Zlatko Buljan
Reviewers: zoran.jovanovic, hvarga, dsanders
Subscribers: llvm-commits, petarj
Differential Revision: http://reviews.llvm.org/D13235
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249416 91177308-0d34-0410-b5e6-96231b3b80d8
If the mask of a select instruction is a ConstantVector, method
SimplifyDemandedVectorElts iterates over the mask elements to identify which
values are selected from the select inputs.
Before this patch, method SimplifyDemandedVectorElts always used method
Constant::isNullValue() to check if a value in the mask was zero. Unfortunately
that method always returns false when called on a ConstantExpr.
This patch fixes the problem in SimplifyDemandedVectorElts by adding an explicit
check for ConstantExpr values. Now, if a value in the mask is a ConstantExpr, we
avoid calling isNullValue() on it.
Fixes PR24922.
Differential Revision: http://reviews.llvm.org/D13219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249390 91177308-0d34-0410-b5e6-96231b3b80d8
