[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] Use zext's nneg flag for icmp folding (#70845)

This PR fixes https://github.com/llvm/llvm-project/issues/55013 : the
max intrinsics is not generated for this simple loop case :
https

[InstCombine] Use zext's nneg flag for icmp folding (#70845)

This PR fixes https://github.com/llvm/llvm-project/issues/55013 : the
max intrinsics is not generated for this simple loop case :
https://godbolt.org/z/hxz1xhMPh. This is caused by a ICMP not being
folded into a select, thus not generating the max intrinsics.

For the story :

Since LLVM 14, SCCP pass got smarter by folding sext into zext for
positive ranges : https://reviews.llvm.org/D81756. After this change,
InstCombine was sometimes unable to fold ICMP correctly as both of the
arguments pointed to mismatched zext/sext. To fix this, @rotateright
implemented this fix : https://reviews.llvm.org/D124419 that tries to
resolve the mismatch by knowing if the argument of a zext is positive
(in which case, it is like a sext) by using ValueTracking, however
ValueTracking is not smart enough to infer that the value is positive in
some cases. Recently, @nikic implemented #67982 which keeps the
information that a zext is non-negative. This PR simply uses this
information to do the folding accordingly.

TLDR : This PR uses the recent nneg tag on zext to fold the icmp
accordingly in instcombine.

This PR also contains test cases for sext/zext folding with InstCombine
as well as a x86 regression tests for the max/min case.

show more ...

[InstCombine] Infer nneg on zext when forming from non-negative sext (#70706)

Builds on #67982 which recently introduced the nneg flag on a zext
instruction. InstCombine is one of our largest canon

[InstCombine] Infer nneg on zext when forming from non-negative sext (#70706)

Builds on #67982 which recently introduced the nneg flag on a zext
instruction. InstCombine is one of our largest canonicalizers of zext
from non-negative sext instructions, so set the flag there.

show more ...

[InstCombine] Fold `(icmp eq/ne (zext i1 X) (sext i1 Y))`-> `(icmp eq/ne (or X, Y), 0)`

This comes up when adding two `bool` types in C/C++
```
bool foo(bool a, bool b) {
return a + b;

[InstCombine] Fold `(icmp eq/ne (zext i1 X) (sext i1 Y))`-> `(icmp eq/ne (or X, Y), 0)`

This comes up when adding two `bool` types in C/C++
```
bool foo(bool a, bool b) {
return a + b;
}
...
->
define i1 @foo(i1 %a, i1 %b) {
%conv = zext i1 %a to i32
%conv3.neg = sext i1 %b to i32
%tobool4 = icmp ne i32 %conv, %conv3.neg
ret i1 %tobool4
}
```

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

Reviewed By: nikic

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

show more ...

[InstCombine] Add tests for folding `(icmp eq/ne (zext i1) (sext i1))`; NFC

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

[InstCombine] try to fold icmp with mismatched extended operands

If a value is known to be non-negative and zexted,
that's the same thing as sexted.

So for the purpose of looking past the casts wit

[InstCombine] try to fold icmp with mismatched extended operands

If a value is known to be non-negative and zexted,
that's the same thing as sexted.

So for the purpose of looking past the casts with
an icmp, treat it as if it was a sext:
https://alive2.llvm.org/ce/z/_BDsGV

This is necessary, but not enough to solve the
motivating problem:
https://github.com/llvm/llvm-project/issues/55013

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

show more ...

[InstCombine] add tests for icmp with extended operands; NFC