[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)

[InstCombine] Add function attribute `instcombine-no-verify-fixpoint` (#113822)

This patch introduces a function attribute
`instcombine-no-verify-fixpoint` to avoids disabling fix-point
verificati

[InstCombine] Add function attribute `instcombine-no-verify-fixpoint` (#113822)

This patch introduces a function attribute
`instcombine-no-verify-fixpoint` to avoids disabling fix-point
verification for unrelated tests in the same file.
Address comment
https://github.com/llvm/llvm-project/pull/112642#discussion_r1804714387.

show more ...

[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 ...

[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 ...

[InstCombine] fold `(icmp eq/ne (or disjoint x, C0), C1)` -> `(icmp eq/ne x, C0^C1)`

Proof: https://alive2.llvm.org/ce/z/m3xoo_

Closes #87734

[InstCombine] Add tests for folding `(icmp eq/ne (or disjoint x, C0), C1)`; NFC

[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 ...

[InstCombine] Fold icmp or sub chain ((x1 - y1) | (x2 - y2)) == 0

Improve ((x1 ^ y1) | (x2 ^ y2)) == 0 transform to also support sub ((x1 - y1) | (x2 - y2)) == 0.
Depends D155703.

Differential Revi

[InstCombine] Fold icmp or sub chain ((x1 - y1) | (x2 - y2)) == 0

Improve ((x1 ^ y1) | (x2 ^ y2)) == 0 transform to also support sub ((x1 - y1) | (x2 - y2)) == 0.
Depends D155703.

Differential Revision: https://reviews.llvm.org/D155704

show more ...

[InstCombine] Fold icmp or sub chain ((x1 - y1) | (x2 - y2)) == 0 tests

Precommit tests for D155704.

Differential Revision: https://reviews.llvm.org/D155703

[InstCombine] Generalise ((x1 ^ y1) | (x2 ^ y2)) == 0 transform

Generalise ((x1 ^ y1) | (x2 ^ y2)) == 0 transform to more than two pairs of variables https://github.com/llvm/llvm-project/issues/5783

[InstCombine] Generalise ((x1 ^ y1) | (x2 ^ y2)) == 0 transform

Generalise ((x1 ^ y1) | (x2 ^ y2)) == 0 transform to more than two pairs of variables https://github.com/llvm/llvm-project/issues/57831.
Depends D154384.

Reviewed By: goldstein.w.n, nikic

Differential Revision: https://reviews.llvm.org/D154306

show more ...

[InstCombine] Generalise ((x1 ^ y1) | (x2 ^ y2)) == 0 transform tests

Precommit tests for D154306.

Differential Revision: https://reviews.llvm.org/D154384

[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 ...

[InstCombine] fold signbit check of X | (X -1)

There may be some other patterns like this or a generalization,
but this is an example that I noticed would definitely regress
with a planned follow-up

[InstCombine] fold signbit check of X | (X -1)

There may be some other patterns like this or a generalization,
but this is an example that I noticed would definitely regress
with a planned follow-up to D111410.

https://alive2.llvm.org/ce/z/GVpQDb

show more ...

[InstCombine] add signbit check for or'd operands; NFC

[InstCombine] fold icmp equality with 'or' mask ops

This could go either direction since the instruction
count is the same either way, but there are a few
reasons to prefer this:
1. We already do th

[InstCombine] fold icmp equality with 'or' mask ops

This could go either direction since the instruction
count is the same either way, but there are a few
reasons to prefer this:
1. We already do the related transform with 'and'
(see just above the new code).
2. We try (too hard) to compensate for not having this
and possibly other folds in transformZExtICmp(),
and that leads to bugs like https://llvm.org/PR51762 .
3. Codegen looks better across a variety of targets.

https://alive2.llvm.org/ce/z/uEgn4P

show more ...

[InstCombine] add tests for icmp with 'or' ops; NFC

[InstCombine] generalize canonicalization of masked equality comparisons

(X | MaskC) == C --> (X & ~MaskC) == C ^ MaskC
(X | MaskC) != C --> (X & ~MaskC) != C ^ MaskC

We have more analyis for '

[InstCombine] generalize canonicalization of masked equality comparisons

(X | MaskC) == C --> (X & ~MaskC) == C ^ MaskC
(X | MaskC) != C --> (X & ~MaskC) != C ^ MaskC

We have more analyis for 'and' patterns and already lean this way
in the existing code, so this should be neutral or better in IR.

If this does not do as well in codegen, the problem already exists
and we should fix that based on target costs/heuristics.

http://volta.cs.utah.edu:8080/z/oP3ecL

define void @src(i8 %x, i8 %OrC, i8 %C, i1* %p0, i1* %p1) {
%or = or i8 %x, %OrC
%eq = icmp eq i8 %or, %C
store i1 %eq, i1* %p0

%ne = icmp ne i8 %or, %C
store i1 %ne, i1* %p1
ret void
}

define void @tgt(i8 %x, i8 %OrC, i8 %C, i1* %p0, i1* %p1) {
%NotOrC = xor i8 %OrC, -1
%a = and i8 %x, %NotOrC
%NewC = xor i8 %C, %OrC
%eq = icmp eq i8 %a, %NewC
store i1 %eq, i1* %p0

%ne = icmp ne i8 %a, %NewC
store i1 %ne, i1* %p1
ret void
}

show more ...

[InstCombine] add tests for icmp with bitmask logic op; NFC