| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI
Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne.
llvm-svn: 307292
|
|
|
|
| |
llvm-svn: 305583
|
|
|
|
| |
llvm-svn: 305579
|
|
|
|
|
|
|
| |
Whenever we don't know what to do with an instruction, we send
it to overdefined anyway.
llvm-svn: 305575
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33737
llvm-svn: 305132
|
|
|
|
|
|
|
|
|
|
| |
Instead of using the SCCP homegrown one. We should eventually
make the private SCCP version disappear, but that wont' be today.
PR33143 tracks this issue.
Add braces for consistency while here. No functional change intended.
llvm-svn: 303706
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and to expose a handle to represent the actual case rather than having
the iterator return a reference to itself.
All of this allows the iterator to be used with common STL facilities,
standard algorithms, etc.
Doing this exposed some missing facilities in the iterator facade that
I've fixed and required some work to the actual iterator to fully
support the necessary API.
Differential Revision: https://reviews.llvm.org/D31548
llvm-svn: 300032
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 299830
|
|
|
|
|
|
| |
There's no need to have two separate APIs.
llvm-svn: 297253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 296281
|
|
|
|
|
|
|
| |
It's not clear the change I made a good idea, and it definitely needs
further discussion. Thanks to Eli for pointing out.
llvm-svn: 293846
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 293799
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29360
llvm-svn: 293727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 292531
|
|
|
|
| |
llvm-svn: 292519
|
|
|
|
| |
llvm-svn: 291400
|
|
|
|
| |
llvm-svn: 289519
|
|
|
|
| |
llvm-svn: 289406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 289175
|
|
|
|
|
|
|
| |
Currently SCCP folds the value to -1, while ConstantProp folds to
0. This changes SCCP to do what ConstantFolding does.
llvm-svn: 289147
|
|
|
|
|
|
| |
This reverts commit r288725 as it broke a bot.
llvm-svn: 288759
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 288725
|
|
|
|
| |
llvm-svn: 288325
|
|
|
|
| |
llvm-svn: 288324
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 287709
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 279647
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278417
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 278078
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 278077
|
|
|
|
|
|
|
|
|
| |
We can replace the return values with undef if we replaced all
the call uses with a constant/undef.
Differential Revision: https://reviews.llvm.org/D22336
llvm-svn: 276174
|
|
|
|
|
|
|
| |
I've been hitting those already while working on SCCP and I think
it's be useful to provide a more explanatory diagnostic.
llvm-svn: 276007
|
|
|
|
| |
llvm-svn: 275593
|
|
|
|
|
|
|
|
| |
.. enough to cause LTO compile time to regress insanely.
Thanks *a lot* to Rafael for reporting the problem and testing
the fix!
llvm-svn: 275468
|
|
|
|
|
|
| |
Thanks to Eli for the suggestion!
llvm-svn: 275366
|
|
|
|
|
|
|
|
|
|
|
| |
values are constant.
This now should also work with the interprocedural variant of the pass.
Slightly easier now that the yak is shaved.
Differential Revision: http://reviews.llvm.org/D22329
llvm-svn: 275363
|
|
|
|
| |
llvm-svn: 275357
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 275339
|
|
|
|
| |
llvm-svn: 275308
|
|
|
|
| |
llvm-svn: 275307
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D22269
llvm-svn: 275208
|
|
|
|
|
|
| |
Thanks to Eli Friedman for pointing out in his post-commit review!
llvm-svn: 275084
|
|
|
|
|
|
|
|
|
|
| |
In the solver, isUndefined() does really mean "we don't know the
value yet" rather than "this is an UndefinedValue". Discussed with
Eli Friedman.
Differential Revision: http://reviews.llvm.org/D22192
llvm-svn: 275004
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 274995
|
|
|
|
|
|
|
|
|
| |
This should be slightly more efficient and could avoid spurious overdefined
markings, as Eli pointed out.
Differential Revision: http://reviews.llvm.org/D22122
llvm-svn: 274905
|
|
|
|
|
|
| |
Only minor manual fixes. No functionality change intended.
llvm-svn: 273808
|
|
|
|
|
|
| |
This reverts commit r273778, it seems to break UBSan :/
llvm-svn: 273779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
llvm-svn: 273778
|
|
|
|
|
|
| |
This fixes PR28269.
llvm-svn: 273521
|
|
|
|
| |
llvm-svn: 271149
|
|
|
|
| |
llvm-svn: 270074
|