|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, 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, llvmorg-18.1.4, llvmorg-18.1.3 |
|
| #
166c1849 |
| 01-Apr-2024 |
Noah Goldstein <goldstein.w.n@gmail.com> |
[InstCombine] Fold `(icmp eq/ne (xor x, y), C1)` even if multiuse
Two folds unlocked:
`(icmp eq/ne (xor x, C0), C1)` -> `(icmp eq/ne x, C2)`
`(icmp eq/ne (xor x, y), 0)` -> `(icmp eq/ne x, y
[InstCombine] Fold `(icmp eq/ne (xor x, y), C1)` even if multiuse
Two folds unlocked:
`(icmp eq/ne (xor x, C0), C1)` -> `(icmp eq/ne x, C2)`
`(icmp eq/ne (xor x, y), 0)` -> `(icmp eq/ne x, y)`
This fixes regressions assosiated with #87180
Closes #87275
show more ...
|
| #
27084f73 |
| 01-Apr-2024 |
Noah Goldstein <goldstein.w.n@gmail.com> |
[InstCombine] Add tests for folding `(icmp eq/ne (xor x, C0), C1)`; NFC
|
|
Revision tags: 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 |
|
| #
c4e2fcff |
| 29-Sep-2023 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[InstCombine] Don't simplify `icmp eq/ne OneUse(A ^ Cst1), Cst2` in foldICmpEquality
This special case will be handled in foldICmpXorConstant later.
See also commit e9cb50a1e351e90be1a8e4ac1a4564cfc
[InstCombine] Don't simplify `icmp eq/ne OneUse(A ^ Cst1), Cst2` in foldICmpEquality
This special case will be handled in foldICmpXorConstant later.
See also commit e9cb50a1e351e90be1a8e4ac1a4564cfc44a984b.
show more ...
|
| #
e9cb50a1 |
| 29-Sep-2023 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[InstCombine] Fix infinite loop in #67273
Closes #67783.
|
| #
e158add1 |
| 26-Sep-2023 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[InstCombine] Canonicalize `icmp eq/ne (A ^ C), B` to `icmp eq/ne (A ^ B), C` (#67273)
This patch canonicalizes `icmp eq/ne (A ^ Cst), B` to `icmp eq/ne (A ^ B), Cst` since the latter form exposes m
[InstCombine] Canonicalize `icmp eq/ne (A ^ C), B` to `icmp eq/ne (A ^ B), C` (#67273)
This patch canonicalizes `icmp eq/ne (A ^ Cst), B` to `icmp eq/ne (A ^ B), Cst` since the latter form exposes more optimizations.
Proof: https://alive2.llvm.org/ce/z/9DbhGc
Fixes #65968.
show more ...
|
| #
6169e452 |
| 24-Sep-2023 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[InstCombine] Add pre-commit tests for PR65968. NFC.
|