Summary:
Resolve indirect branch target when possible.
This potentially eliminates more basicblocks and result in better evaluation for phi and other things.
Reviewers: davide, efriedma, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30322
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@299830 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
BranchInst, SwitchInst (with non-default case) with Undef as input is not
possible at this point. As we always default-fold terminator to one target in
ResolvedUndefsIn and set the input accordingly.
So we should only have constantint/blockaddress here.
If ConstantFoldTerminator fails, that could mean 2 things.
1. ConstantFoldTerminator is doing something unexpected, i.e. not folding on constantint
or blockaddress and not making blocks that should be dead dead.
2. This is not a terminator on constantint or blockaddress. Its on a constant or
overdefined, then this block should not be dead.
In both cases, we should assert.
Reviewers: davide, efriedma, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296281 91177308-0d34-0410-b5e6-96231b3b80d8
It's not clear the change I made a good idea, and it definitely needs
further discussion. Thanks to Eli for pointing out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293846 91177308-0d34-0410-b5e6-96231b3b80d8
This tries to address what Hal defined (in the post-commit review of
r293727) a long-standing problem with noinline, where we end up
de facto inlining trivial functions e.g.
__attribute__((noinline)) int patatino(void) { return 5; }
because of return value propagation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293799 91177308-0d34-0410-b5e6-96231b3b80d8
This can prove that:
extern int f;
int g() {
int x = 0;
for (int i = 0; i < 365; ++i) {
x /= f;
}
return x;
}
always returns zero. Thanks to Sanjoy for confirming this
transformation actually made sense (bugs are mine).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292531 91177308-0d34-0410-b5e6-96231b3b80d8
The motivating example is:
extern int patatino;
int goo() {
int x = 0;
for (int i = 0; i < 1000000; ++i) {
x *= patatino;
}
return x;
}
Currently SCCP will not realize that this function returns always zero,
therefore will try to unroll and vectorize the loop at -O3 producing an
awful lot of (useless) code. With this change, it will just produce:
0000000000000000 <g>:
xor %eax,%eax
retq
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289175 91177308-0d34-0410-b5e6-96231b3b80d8
Currently SCCP folds the value to -1, while ConstantProp folds to
0. This changes SCCP to do what ConstantFolding does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289147 91177308-0d34-0410-b5e6-96231b3b80d8
There are two cases handled here:
1) a branch on undef
2) a switch with an undef condition.
Both cases are currently handled by ResolvedUndefsIn. If we have
a branch on undef, we force its value to false (which is trivially
foldable). If we have a switch on undef, we force to the first
constant (which is also foldable).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288725 91177308-0d34-0410-b5e6-96231b3b80d8
We visit and/or, we try to derive a lattice value for the
instruction even if one of the operands is overdefined.
If the non-overdefined value is still 'unknown' just return and wait
for ResolvedUndefsIn to "plug in" the correct value. This simplifies
the logic a bit. While I'm here add tests for missing cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287709 91177308-0d34-0410-b5e6-96231b3b80d8
I'm not sure if the `!isa<CallInst>(Inst) &&
!isa<TerminatorInst>(Inst))` bit is correct either, but this fixes the
case we know is broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279647 91177308-0d34-0410-b5e6-96231b3b80d8
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.
Thanks to David for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278078 91177308-0d34-0410-b5e6-96231b3b80d8
Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.
Thanks to David for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278077 91177308-0d34-0410-b5e6-96231b3b80d8
I've been hitting those already while working on SCCP and I think
it's be useful to provide a more explanatory diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276007 91177308-0d34-0410-b5e6-96231b3b80d8
.. enough to cause LTO compile time to regress insanely.
Thanks *a lot* to Rafael for reporting the problem and testing
the fix!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275468 91177308-0d34-0410-b5e6-96231b3b80d8
The code was pretty much copy-pasted between SCCP and IPSCCP. The situation
became clearly worse after I introduced the support for folding structs in
SCCP. This commit is NFC as we currently (still) skip the replacement
step in IPSCCP, but I'll change this soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275339 91177308-0d34-0410-b5e6-96231b3b80d8
This code was already commented out and it made some weird assumptions,
e.g. using isUndefined() as "this value is UndefValue" instead of
"we haven't computed this value is yet". Thanks to Eli Friedman for
pointing out where I was wrong (and where this code was wrong).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274995 91177308-0d34-0410-b5e6-96231b3b80d8
SimplifyCFG had logic to insert calls to llvm.trap for two very
particular IR patterns: stores and invokes of undef/null.
While InstCombine canonicalizes certain undefined behavior IR patterns
to stores of undef, phase ordering means that this cannot be relied upon
in general.
There are much better tools than llvm.trap: UBSan and ASan.
N.B. I could be argued into reverting this change if a clear argument as
to why it is important that we synthesize llvm.trap for stores, I'd be
hard pressed to see why it'd be useful for invokes...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273778 91177308-0d34-0410-b5e6-96231b3b80d8
TargetLibraryInfoWrapperPass is a dependency of
SCCP but it's not listed as such. Chandler pointed
out this is an easy mistake to make which only
surfaces in weird crashes with some flag combinations.
This code will go away anyway at some point in the
future, but as long as it's (still) exercised, try
to make it correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269589 91177308-0d34-0410-b5e6-96231b3b80d8
Shifts beyond the bitwidth are undef but SCCP resolved them to zero.
Instead, DTRT and resolve them to undef.
This reimplements the transform which caused PR27712.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269269 91177308-0d34-0410-b5e6-96231b3b80d8
