| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
phi node itself if it occurs in an unreachable basic block. Protect
against this. Hopefully this will fix some more buildbots.
llvm-svn: 119493
|
|
|
|
|
|
|
|
| |
simplified to itself (this can only happen in unreachable blocks).
Change it to return null instead. Hopefully this will fix some
buildbot failures.
llvm-svn: 119490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class, uses DominatorTree which is an analysis. This change moves all of
the tricky hasConstantValue logic to SimplifyInstruction, and replaces it
with a very simple literal implementation. I already taught users of
hasConstantValue that need tricky stuff to use SimplifyInstruction instead.
I didn't update InlineFunction because the IR looks like it might be in a
funky state at the point it calls hasConstantValue, which makes calling
SimplifyInstruction dangerous since it can in theory do a lot of tricky
reasoning. This may be a pessimization, for example in the case where
all phi node operands are either undef or a fixed constant.
llvm-svn: 119459
|
|
|
|
|
|
| |
While there, add a note about an inefficiency I noticed.
llvm-svn: 119458
|
|
|
|
|
|
| |
This fixes some extreme compile times on unrolled sha512 code.
llvm-svn: 119455
|
|
|
|
|
|
|
|
|
|
|
| |
over a phi node by applying it to each operand may be wrong if the
operation and the phi node are mutually interdependent (the testcase
has a simple example of this). So only do this transform if it would
be correct to perform the operation in each predecessor of the block
containing the phi, i.e. if the other operands all dominate the phi.
This should fix the FFMPEG snow.c regression reported by İsmail Dönmez.
llvm-svn: 119347
|
|
|
|
|
|
| |
values that are equal to the phi itself.
llvm-svn: 119161
|
|
|
|
|
|
| |
it to get better phi node simplification.
llvm-svn: 119055
|
|
|
|
|
|
|
|
|
|
| |
offload the work to hasConstantValue rather than do something more
complicated (such handling mutually recursive phis) because (1) it is
not clear it is worth it; and (2) if it is worth it, maybe such logic
would be better placed in hasConstantValue. Adjust some GVN tests
which are now cleaned up much further (eg: all phi nodes are removed).
llvm-svn: 119043
|
|
|
|
|
|
|
|
|
|
|
| |
operands are the phi node itself or undef, then return undef.
This logic already existed at a higher level so in practice it
shouldn't make the slightest difference. Note that this code
could be replaced by a call to PN->hasConstantValue(). However
since we bail out the moment we see a non-constant operand, it
is more efficient to have a specialized version of that logic.
llvm-svn: 119041
|
|
|
|
| |
llvm-svn: 119038
|
|
|
|
| |
llvm-svn: 119001
|
|
|
|
|
|
| |
at least.
llvm-svn: 118890
|
|
|
|
| |
llvm-svn: 118884
|
|
|
|
|
|
| |
and vaarg instructions.
llvm-svn: 118845
|
|
|
|
| |
llvm-svn: 118842
|
|
|
|
| |
llvm-svn: 118822
|
|
|
|
|
|
| |
these points.
llvm-svn: 118752
|
|
|
|
|
|
| |
it, so that it doesn't appear to be a known size.
llvm-svn: 118748
|
|
|
|
|
|
| |
the reverse map too. This fixes seflhost build errors.
llvm-svn: 118729
|
|
|
|
|
|
|
|
| |
function specific local variable's info.
This fixes radar 8653152. I am checking in testcase as a separate check-in.
llvm-svn: 118726
|
|
|
|
|
|
| |
for a given instruction into a helper function.
llvm-svn: 118723
|
|
|
|
|
|
| |
type is insufficient for, or incompatible with, the current query.
llvm-svn: 118721
|
|
|
|
|
|
| |
Probably it should just be 1, but compromise with 3.
llvm-svn: 118718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
references. For example, this allows gvn to eliminate the load in
this example:
void foo(int n, int* p, int *q) {
p[0] = 0;
p[1] = 1;
if (n) {
*q = p[0];
}
}
llvm-svn: 118714
|
|
|
|
|
|
|
|
|
| |
nodes can be used in loops, this could result in infinite looping
if there is no recursion limit, so add such a limit. It is also
used for the SelectInst case because in theory there could be an
infinite loop there too if the basic block is unreachable.
llvm-svn: 118694
|
|
|
|
|
|
| |
it, and to be consistent.
llvm-svn: 118692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simplifications performed here never create new instructions, they
only return existing instructions (or a constant), and so are always a
win. In theory they should transform (for example)
%z = and i32 %x, %y
%s = select i1 %cond, i32 %y, i32 %z
%r = and i32 %x, %s
into
%r = and i32 %x, y
but in practice they get into a fight with instcombine, and lose.
Unfortunately instcombine does a poor job in this case. Nonetheless
I'm committing this transform to make it easier to discuss what to
do to make peace with instcombine.
llvm-svn: 118679
|
|
|
|
|
|
| |
chaining and simplify FunctionAttrs' GetModRefBehavior logic.
llvm-svn: 118660
|
|
|
|
| |
llvm-svn: 118623
|
|
|
|
| |
llvm-svn: 118621
|
|
|
|
| |
llvm-svn: 118618
|
|
|
|
| |
llvm-svn: 118516
|
|
|
|
|
|
|
| |
pointsToConstantMemory code to guard against possible
compile time slowdowns.
llvm-svn: 118440
|
|
|
|
| |
llvm-svn: 118416
|
|
|
|
|
|
|
|
|
|
|
|
| |
to optionally look for constant or local (alloca) memory.
Teach BasicAliasAnalysis::pointsToConstantMemory to look through Select
and Phi nodes, and to support looking for local memory.
Remove FunctionAttrs' PointsToLocalOrConstantMemory function, now that
AliasAnalysis knows all the tricks that it knew.
llvm-svn: 118412
|
|
|
|
|
|
|
| |
getModRefBehavior now, since it now understands intrinsics as well
as normal functions.
llvm-svn: 118411
|
|
|
|
|
|
| |
to analyze intrinsic functions.
llvm-svn: 118409
|
|
|
|
|
|
|
| |
of a select instruction, the same as already exists for integer
comparisons.
llvm-svn: 118379
|
|
|
|
|
|
|
|
| |
of a select instruction, see if doing the compare with the
true and false values of the select gives the same result.
If so, that can be used as the value of the comparison.
llvm-svn: 118378
|
|
|
|
| |
llvm-svn: 118257
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
emit debuggging information entries in LLVM IR.
To create debugging information for a pointer, using DIBUilder front-end just needs
DBuilder.CreatePointerType(Ty, Size);
instead of
DebugFactory.CreateDerivedType(llvm::dwarf::DW_TAG_pointer_type,
TheCU, "", getOrCreateMainFile(),
0, Size, 0, 0, 0, OCTy);
llvm-svn: 118248
|
|
|
|
| |
llvm-svn: 118054
|
|
|
|
|
|
|
| |
they may have ValuesAtScopes map entries referencing their outer loops.
This fixes a user-after-free reported in PR8471.
llvm-svn: 117698
|
|
|
|
|
|
| |
from constant memory don't alias any stores.
llvm-svn: 117636
|
|
|
|
| |
llvm-svn: 117317
|
|
|
|
| |
llvm-svn: 117314
|
|
|
|
|
|
| |
bits open for future uses.
llvm-svn: 117301
|
|
|
|
| |
llvm-svn: 117288
|
|
|
|
| |
llvm-svn: 117268
|