| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up the existing code by:
1. Renaming variables
2. Adding local variables
3. Making it vector-safe
This is still guarded by a ConstantInt check, so no functional change is intended.
But this should be ready to go: if we move the ConstantInt check down, all of
these folds should do the right thing for vector types.
llvm-svn: 279150
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also add popcount(n) == bitsize(n) -> n == -1 transformation.
Reviewers: majnemer, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23134
llvm-svn: 279141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
https://reviews.llvm.org/rL279077
https://reviews.llvm.org/rL279101
llvm-svn: 279133
|
| |
|
|
|
|
|
| |
1. Fix variable names
2. Add local variables to reduce code
llvm-svn: 279132
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
https://reviews.llvm.org/rL279077
llvm-svn: 279101
|
| |
|
|
|
|
|
| |
1. Better variable names
2. Remove unnecessary check of ConstantInt
llvm-svn: 279094
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
llvm-svn: 279077
|
| |
|
|
|
|
|
| |
This will enable vector splat folding, but NFC until the callers
have their ConstantInt restrictions removed.
llvm-svn: 279072
|
| |
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
llvm-svn: 279066
|
| |
|
|
|
|
| |
Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970
|
| |
|
|
|
|
|
| |
Use m_APInt for the xor constant, but this is all still guarded by the initial
ConstantInt check, so no vector types should make it in here.
llvm-svn: 278957
|
| |
|
|
|
|
|
|
| |
1. Change variable names
2. Use local variables to reduce code
3. Early exit to reduce indent
llvm-svn: 278955
|
| |
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
llvm-svn: 278945
|
| |
|
|
|
|
|
|
|
| |
1. Change variable names
2. Use local variables to reduce code
3. Use ? instead of if/else
4. Use the APInt variable instead of 'RHS' so the removal of the FIXME code will be direct
llvm-svn: 278944
|
| |
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
llvm-svn: 278935
|
| |
|
|
|
|
|
| |
This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm-svn: 278902
|
| |
|
|
|
|
|
|
|
|
|
| |
1. Fix variable names
2. Add local variables to reduce code
3. Fix code comments
4. Add early exit to reduce indentation
5. Remove 'else' after if -> return
6. Hoist common predicate
llvm-svn: 278864
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 278859
|
| |
|
|
| |
llvm-svn: 278855
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Besides breaking up a 700 line function to improve readability,
this sinks the 'FIXME: ConstantInt' check into each helper. So
now we can independently break that restriction within any of the
helper functions.
As much as possible, the code was only {cut/paste/clang-format}'ed
to minimize risk (no functional changes intended), so several more
readability improvements are still possible.
llvm-svn: 278828
|
| |
|
|
|
|
|
|
|
|
|
| |
There's some formatting and pointer deref ugliness here that I intend to fix in
subsequent patches. The overall goal is to refactor the obnoxiously long switch
and incrementally remove the restriction to scalar types (allow folds for vector
splats). This patch introduces the use of m_APInt which means the RHSV reference
is now a pointer (and may have matched a vector splat), but the check of 'RHS'
remains, so vector folds are disallowed and no functional change is intended.
llvm-svn: 278816
|
| |
|
|
|
|
|
|
| |
This is part of an effort to constify ValueTracking.cpp. This change is
to methods which need const Value* instead of Value* to go with the upcoming
changes to ValueTracking.
llvm-svn: 278528
|
| |
|
|
|
|
|
|
|
| |
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
llvm-svn: 278469
|
| |
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278417
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D23291
llvm-svn: 278364
|
| |
|
|
| |
llvm-svn: 278342
|
| |
|
|
| |
llvm-svn: 278340
|
| |
|
|
| |
llvm-svn: 278339
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
The DEBUG() macro already does this.
llvm-svn: 278049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The correctness fix here is that when we CSE a load with another load,
we need to combine the metadata on the two loads. This matches the
behavior of other passes, like instcombine and GVN.
There's also a minor optimization improvement here: for load PRE, the
aliasing metadata on the inserted load should be the same as the
metadata on the original load. Not sure why the old code was throwing
it away.
Issue found by inspection.
Differential Revision: http://reviews.llvm.org/D21460
llvm-svn: 277977
|
| |
|
|
| |
llvm-svn: 277950
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: majnemer
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D23231
llvm-svn: 277910
|
| |
|
|
|
|
|
|
|
|
| |
Note that this fold really belongs in InstSimplify.
Refactoring here anyway as an intermediate step because
there's a planned addition to this function in D23134.
Differential Revision: https://reviews.llvm.org/D23223
llvm-svn: 277883
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Turn (select C, (sext A), B) into (sext (select C, A, B')) when A is i1 and
B is a compatible constant, also for zext instead of sext. This will then be
further folded into logical operations.
The transformation would be valid for non-i1 types as well, but other parts of
InstCombine prefer to have sext from non-i1 as an operand of select.
Motivated by the shader compiler frontend in Mesa for AMDGPU, which emits i32
for boolean operations. With this change, the boolean logic is fully
recovered.
Reviewers: majnemer, spatel, tstellarAMD
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D22747
llvm-svn: 277801
|
| |
|
|
| |
llvm-svn: 277793
|
| |
|
|
| |
llvm-svn: 277792
|
| |
|
|
|
|
|
|
|
|
| |
Add a generalized IRBuilderCallbackInserter, which is just given a
callback to execute after insertion. This can be used to get rid of
the custom inserter in InstCombine, which will in turn allow me to add
target specific InstCombineCalls API for intrinsics without horrible
layering violations.
llvm-svn: 277784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This concludes the splat vector enhancements for foldICmpEqualityWithConstant().
Other commits in this series:
https://reviews.llvm.org/rL277762
https://reviews.llvm.org/rL277752
https://reviews.llvm.org/rL277738
https://reviews.llvm.org/rL277731
https://reviews.llvm.org/rL277659
https://reviews.llvm.org/rL277638
https://reviews.llvm.org/rL277629
llvm-svn: 277779
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 277762
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 277752
|
| |
|
|
|
|
|
|
|
| |
constant vectors
I'm removing a misplaced pair of more specific folds from InstCombine in this patch as well,
so we know where those folds are happening in InstSimplify.
llvm-svn: 277738
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 277731
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title.
Reviewers: majnemer, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23139
llvm-svn: 277694
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 277659
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 277638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggressive cast-folding
Summary:
InstCombine unfolds expressions of the form `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` such that in a later iteration of InstCombine the exposed `zext(icmp)` instructions can be optimized. We now combine this unfolding and the subsequent `zext(icmp)` optimization to be performed together. Since the unfolding doesn't happen separately anymore, we also again enable the folding of `logic(cast(icmp), cast(icmp))` expressions to `cast(logic(icmp, icmp))` which had been disabled due to its interference with the unfolding transformation.
Tested via `make check` and `lnt`.
Background
==========
For a better understanding on how it came to this change we subsequently summarize its history. In commit r275989 we've already tried to enable the folding of `logic(cast(icmp), cast(icmp))` to `cast(logic(icmp, icmp))` which had to be reverted in r276106 because it could lead to an endless loop in InstCombine (also see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160718/374347.html). The root of this problem is that in `visitZExt()` in InstCombineCasts.cpp there also exists a reverse of the above folding transformation, that unfolds `zext(or(icmp, icmp))` to `or(zext(icmp), zext(icmp))` in order to expose `zext(icmp)` operations which would then possibly be eliminated by subsequent iterations of InstCombine. However, before these `zext(icmp)` would be eliminated the folding from r275989 could kick in and cause InstCombine to endlessly switch back and forth between the folding and the unfolding transformation. This is the reason why we now combine the `zext`-unfolding and the elimination of the exposed `zext(icmp)` to happen at one go because this enables us to still allow the cast-folding in `logic(cast(icmp), cast(icmp))` without entering an endless loop again.
Details on the submitted changes
================================
- In `visitZExt()` we combine the unfolding and optimization of `zext` instructions.
- In `transformZExtICmp()` we have to use `Builder->CreateIntCast()` instead of `CastInst::CreateIntegerCast()` to make sure that the new `CastInst` is inserted in a `BasicBlock`. The new calls to `transformZExtICmp()` that we introduce in `visitZExt()` would otherwise cause according assertions to be triggered (in our case this happend, for example, with lnt for the MultiSource/Applications/sqlite3 and SingleSource/Regression/C++/EH/recursive-throw tests). The subsequent usage of `replaceInstUsesWith()` is necessary to ensure that the new `CastInst` replaces the `ZExtInst` accordingly.
- In InstCombineAndOrXor.cpp we again allow the folding of casts on `icmp` instructions.
- The instruction order in the optimized IR for the zext-or-icmp.ll test case is different with the introduced changes.
- The test cases in zext.ll have been adopted from the reverted commits r275989 and r276105.
Reviewers: grosser, majnemer, spatel
Subscribers: eli.friedman, majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D22864
Contributed-by: Matthias Reisinger <d412vv1n@gmail.com>
llvm-svn: 277635
|
| |
|
|
|
|
|
|
|
| |
splat vectors
This removes the restriction for the icmp constant, but as noted by the FIXME comments,
we still need to change individual checks for binop operand constants.
llvm-svn: 277629
|
| |
|
|
| |
llvm-svn: 277612
|
| |
|
|
|
|
| |
Clean-up before changing this to allow folds for vectors.
llvm-svn: 277538
|