|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
| #
38fffa63 |
| 06-Nov-2024 |
Paul Walker <paul.walker@arm.com> |
[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)
|
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
| #
a1058776 |
| 21-Aug-2024 |
Nikita Popov <npopov@redhat.com> |
[InstCombine] Remove some of the complexity-based canonicalization (#91185)
The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be can
[InstCombine] Remove some of the complexity-based canonicalization (#91185)
The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be canonicalized away. This is
indeed very useful to e.g. know that constants are always on the right.
However, this is only useful if the canonicalization is actually
reliable. This is the case for constants, but not for arguments: Moving
these to the right makes it look like the "more complex" expression is
guaranteed to be on the left, but this is not actually the case in
practice. It fails as soon as you replace the argument with another
instruction.
The end result is that it looks like things correctly work in tests,
while they actually don't. We use the "thwart complexity-based
canonicalization" trick to handle this in tests, but it's often a
challenge for new contributors to get this right, and based on the
regressions this PR originally exposed, we clearly don't get this right
in many cases.
For this reason, I think that it's better to remove this complexity
canonicalization. It will make it much easier to write tests for
commuted cases and make sure that they are handled.
show more ...
|
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
| #
396cdabe |
| 19-Apr-2024 |
Nikita Popov <npopov@redhat.com> |
[PatternMatch] Allow poison in api_pred_ty matchers (#89188)
This allows vector splats containing poison for matchers using
api_pred_ty, making the behavior consistent with cst_pred_ty. In other
w
[PatternMatch] Allow poison in api_pred_ty matchers (#89188)
This allows vector splats containing poison for matchers using
api_pred_ty, making the behavior consistent with cst_pred_ty. In other
words, previously `m_NonNegative()` allowed splats with poison, while
`m_NonNegative(C)` did not. Now both allow them.
The affected matchers are m_MaxSignedValue, m_Negative, m_NonNegative,
m_StrictlyPositive, m_NonPositive, m_Power2, m_Power2OrZero,
m_NegatedPower2, m_NegatedPower2OrZero, m_LowBitMask and
m_LowBitMaskOrZero when passing in APInt.
I briefly went through the uses of these matchers and didn't spot any
places where allowing poison would be obviously wrong (I initially
thought foldSelectICmpAndBinOp is problematic, but because it does not
reuse the original constants, it's fine).
A problem here is that, despite these matchers appearing in a decent
number of places, we have very little pre-existing test coverage for
these folds with poison vectors, so we don't benefit from alive2
verification.
show more ...
|
| #
1baa3850 |
| 18-Apr-2024 |
Nikita Popov <npopov@redhat.com> |
[IR][PatternMatch] Only accept poison in getSplatValue() (#89159)
In #88217 a large set of matchers was changed to only accept poison
values in splats, but not undef values. This is because we now
[IR][PatternMatch] Only accept poison in getSplatValue() (#89159)
In #88217 a large set of matchers was changed to only accept poison
values in splats, but not undef values. This is because we now use
poison for non-demanded vector elements, and allowing undef can cause
correctness issues.
This patch covers the remaining matchers by changing the AllowUndef
parameter of getSplatValue() to AllowPoison instead. We also carry out
corresponding renames in matchers.
As a followup, we may want to change the default for things like m_APInt
to m_APIntAllowPoison (as this is much less risky when only allowing
poison), but this change doesn't do that.
There is one caveat here: We have a single place
(X86FixupVectorConstants) which does require handling of vector splats
with undefs. This is because this works on backend constant pool
entries, which currently still use undef instead of poison for
non-demanded elements (because SDAG as a whole does not have an explicit
poison representation). As it's just the single use, I've open-coded a
getSplatValueAllowUndef() helper there, to discourage use in any other
places.
show more ...
|
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2 |
|
| #
03dcd9da |
| 11-Apr-2023 |
John McIver <john.mciver.iii@gmail.com> |
[InstCombine] Allow splats with poison/undef in llvm::decomposeBitTestICmp
This change is made to enable conversion of a masked icmp splat vector containing poison/undef to an equality expression.
[InstCombine] Allow splats with poison/undef in llvm::decomposeBitTestICmp
This change is made to enable conversion of a masked icmp splat vector containing poison/undef to an equality expression.
llvm::decomposeBitTestICmp Alive2 correctness examples using splat/masking vectors:
SLT < https://alive2.llvm.org/ce/z/pPTTHh SLE <= https://alive2.llvm.org/ce/z/qQhAmU SGT > https://alive2.llvm.org/ce/z/koFHzF SGE >= https://alive2.llvm.org/ce/z/3SNz2S ULT <u https://alive2.llvm.org/ce/z/W8ktzQ ULE <=u https://alive2.llvm.org/ce/z/G5SdUY UGT >u https://alive2.llvm.org/ce/z/WFwYxq UGE >=u https://alive2.llvm.org/ce/z/DzJszP
Tests have been verified using Alive2:
icmp-logical.ll: @nomask_splat_and_B_allones https://alive2.llvm.org/ce/z/zmJwQU icmp-logical.ll: @nomask_splat_and_B_mixed https://alive2.llvm.org/ce/z/ktzgzd signed-truncation-check.ll: @positive_vec_undef0 https://alive2.llvm.org/ce/z/-sTRLD
Differential Revision: https://reviews.llvm.org/D143032
show more ...
|
|
Revision tags: llvmorg-16.0.1 |
|
| #
88318dfa |
| 04-Apr-2023 |
John McIver <john.mciver.iii@gmail.com> |
[InstCombine][NFC] Update generated variable names in signed-truncation-check.ll
Update signed-truncation-check.ll using latest version of update_test_checks.py.
Differential Revision: https://revi
[InstCombine][NFC] Update generated variable names in signed-truncation-check.ll
Update signed-truncation-check.ll using latest version of update_test_checks.py.
Differential Revision: https://reviews.llvm.org/D143030
show more ...
|
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
| #
acdc419c |
| 04-Feb-2022 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC
Another step moving away from the deprecated syntax of specifying pass pipeline in opt.
Differential Revision: https://r
[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC
Another step moving away from the deprecated syntax of specifying pass pipeline in opt.
Differential Revision: https://reviews.llvm.org/D119081
show more ...
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
f55d1eb3 |
| 28-Nov-2021 |
Sanjay Patel <spatel@rotateright.com> |
[InstCombine] use decomposeBitTestICmp to make icmp (trunc X), C more consistent
This is a follow-on suggested in D112634. Two folds that were added with that patch are subsumed in the call to decom
[InstCombine] use decomposeBitTestICmp to make icmp (trunc X), C more consistent
This is a follow-on suggested in D112634. Two folds that were added with that patch are subsumed in the call to decomposeBitTestICmp, and two other folds are potentially inverted.
The deleted folds were very specialized by instcombine standards because they were restricted to legal integer types based on the data layout. This generalizes the canonical form independent of target/types.
This change has a reasonable chance of exposing regressions either in IR or codegen, but I don't have any evidence for either of those yet. A spot check of asm across several in-tree targets shows variations that I expect are mostly neutral.
We have one improvement in an existing IR test that I noted with a comment. Using mask ops might also make more code match with D114272.
Differential Revision: https://reviews.llvm.org/D114386
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
58ebc79a |
| 09-Nov-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[InstCombine] Strip offset when folding and/or of icmps
When folding and/or of icmps, look through add of a constant and adjust the icmp range instead. Effectively, this decomposes X + C1 < C2 style
[InstCombine] Strip offset when folding and/or of icmps
When folding and/or of icmps, look through add of a constant and adjust the icmp range instead. Effectively, this decomposes X + C1 < C2 style range checks back into a normal range. This allows us to fold comparisons involving two range checks or one range check and some other condition. We had a fold for a really specific case of this (or of range check and eq, and only one one side!) while this handles it in fully generality.
Differential Revision: https://reviews.llvm.org/D113510
show more ...
|
| #
acabad9f |
| 26-Oct-2021 |
Sanjay Patel <spatel@rotateright.com> |
[InstCombine] try to canonicalize icmp with trunc op into mask and cmp
The motivating test is based on: https://llvm.org/PR52260
We have better analysis for X == 0, so try harder to form that.
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
8a156d1c |
| 02-May-2021 |
Juneyoung Lee <aqjune@gmail.com> |
[InstCombine] Fully disable select to and/or i1 folding
This is a patch that disables the poison-unsafe select -> and/or i1 folding.
It has been blocking D72396 and also has been the source of a fe
[InstCombine] Fully disable select to and/or i1 folding
This is a patch that disables the poison-unsafe select -> and/or i1 folding.
It has been blocking D72396 and also has been the source of a few miscompilations described in llvm.org/pr49688 . D99674 conditionally blocked this folding and successfully fixed the latter one. The former one was still blocked, and this patch addresses it.
Note that a few test functions that has `_logical` suffix are now deoptimized. These are created by @nikic to check the impact of disabling this optimization by copying existing original functions and replacing and/or with select.
I can see that most of these are poison-unsafe; they can be revived by introducing freeze instruction. I left comments at fcmp + select optimizations (or-fcmp.ll, and-fcmp.ll) because I think they are good targets for freeze fix.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D101191
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5 |
|
| #
5207cde5 |
| 04-Apr-2021 |
Juneyoung Lee <aqjune@gmail.com> |
[InstCombine] Conditionally fold select i1 into and/or
This patch fixes llvm.org/pr49688 by conditionally folding select i1 into and/or:
``` select cond, cond2, false -> and cond, cond2 ```
This i
[InstCombine] Conditionally fold select i1 into and/or
This patch fixes llvm.org/pr49688 by conditionally folding select i1 into and/or:
``` select cond, cond2, false -> and cond, cond2 ```
This is not safe if cond2 is poison whereas cond isn’t.
Unconditionally disabling this transformation affects later pipelines that depend on and/or i1s. To minimize its impact, this patch conservatively checks whether cond2 is an instruction that creates a poison or its operand creates a poison. This approach is similar to what InstSimplify's SimplifyWithOpReplaced is doing.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D99674
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
| #
fb063c93 |
| 12-Jan-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[InstCombine] Duplicate tests for logical and/or (NFC)
This replicates existing and/or tests to also test variants using select. This should help us get a more accurate view on which optimizations w
[InstCombine] Duplicate tests for logical and/or (NFC)
This replicates existing and/or tests to also test variants using select. This should help us get a more accurate view on which optimizations we're missing if we disable the select -> and/or fold.
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
cee313d2 |
| 17-Apr-2019 |
Eric Christopher <echristo@gmail.com> |
Revert "Temporarily Revert "Add basic loop fusion pass.""
The reversion apparently deleted the test/Transforms directory.
Will be re-reverting again.
llvm-svn: 358552
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
3534874f |
| 13-Aug-2018 |
Roman Lebedev <lebedev.ri@gmail.com> |
[InstCombine] Re-land: Optimize redundant 'signed truncation check pattern'.
Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned in
[InstCombine] Re-land: Optimize redundant 'signed truncation check pattern'.
Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294}
General pattern: X & Y
Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check.
And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0
Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128
The transform itself ended up being rather horrible, even though i omitted some cases. Surely there is some infrastructure that can help clean this up that i missed?
https://rise4fun.com/Alive/3Ou
The initial commit (rL339610) was reverted, since the first assert was being triggered. The @positive_with_extra_and test now has coverage for that case.
Reviewers: spatel, craig.topper
Reviewed By: spatel
Subscribers: RKSimon, erichkeane, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D50465
llvm-svn: 339621
show more ...
|
| #
93f7e7f0 |
| 13-Aug-2018 |
Roman Lebedev <lebedev.ri@gmail.com> |
[NFC][InstCombine] Add a test for D50465 that used to assert
This is valid to fold, too. https://rise4fun.com/Alive/0lz
llvm-svn: 339619
|
| #
28a42c77 |
| 13-Aug-2018 |
Roman Lebedev <lebedev.ri@gmail.com> |
Revert "[InstCombine] Optimize redundant 'signed truncation check pattern'."
At least one buildbot was able to actually trigger that assert on the top of the function. Will investigate.
This revert
Revert "[InstCombine] Optimize redundant 'signed truncation check pattern'."
At least one buildbot was able to actually trigger that assert on the top of the function. Will investigate.
This reverts commit r339610.
llvm-svn: 339612
show more ...
|
| #
4c475077 |
| 13-Aug-2018 |
Roman Lebedev <lebedev.ri@gmail.com> |
[InstCombine] Optimize redundant 'signed truncation check pattern'.
Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { re
[InstCombine] Optimize redundant 'signed truncation check pattern'.
Summary: This comes with `Implicit Conversion Sanitizer - integer sign change` (D50250): ``` signed char test(unsigned int x) { return x; } ``` `clang++ -fsanitize=implicit-conversion -S -emit-llvm -o - /tmp/test.cpp -O3` * Old: {F6904292} * With this patch: {F6904294}
General pattern: X & Y
Where `Y` is checking that all the high bits (covered by a mask `4294967168`) are uniform, i.e. `%arg & 4294967168` can be either `4294967168` or `0` Pattern can be one of: %t = add i32 %arg, 128 %r = icmp ult i32 %t, 256 Or %t0 = shl i32 %arg, 24 %t1 = ashr i32 %t0, 24 %r = icmp eq i32 %t1, %arg Or %t0 = trunc i32 %arg to i8 %t1 = sext i8 %t0 to i32 %r = icmp eq i32 %t1, %arg This pattern is a signed truncation check.
And `X` is checking that some bit in that same mask is zero. I.e. can be one of: %r = icmp sgt i32 %arg, -1 Or %t = and i32 %arg, 2147483648 %r = icmp eq i32 %t, 0
Since we are checking that all the bits in that mask are the same, and a particular bit is zero, what we are really checking is that all the masked bits are zero. So this should be transformed to: %r = icmp ult i32 %arg, 128
https://rise4fun.com/Alive/3Ou
Reviewers: spatel, craig.topper
Reviewed By: spatel
Subscribers: RKSimon, erichkeane, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D50465
llvm-svn: 339610
show more ...
|
| #
2da1ef5b |
| 13-Aug-2018 |
Roman Lebedev <lebedev.ri@gmail.com> |
[InstCombine][NFC] Tests for 'signed truncation check' optimization
See D50465 for the actual opt itself.
Differential Revision: https://reviews.llvm.org/D50464
llvm-svn: 339602
|