[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][CGP] Move swapMayExposeCSEOpportunities() fold

InstCombine tries to swap compare operands to match sub instructions
in order to expose "CSE opportunities". However, it doesn't really
m

[InstCombine][CGP] Move swapMayExposeCSEOpportunities() fold

InstCombine tries to swap compare operands to match sub instructions
in order to expose "CSE opportunities". However, it doesn't really
make sense to perform this transform in the middle-end, as we cannot
actually CSE the instructions there.

The backend already performs this fold in
https://github.com/llvm/llvm-project/blob/18f5446a45da5a61dbfb1b7667d27fb441ac62db/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L4236
on the SDAG level, however this only works within a single basic block.

To handle cross-BB cases, we do need to handle this in the IR layer.
This patch moves the fold from InstCombine to CGP in the backend,
while keeping the same (somewhat dubious) heuristic.

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

show more ...

[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] use redirect of input file in regression tests; NFC

This is a repeat of 1880092722 from 2009. We should have less risk
of hitting bugs at this point because we auto-generate positive C

[InstCombine] use redirect of input file in regression tests; NFC

This is a repeat of 1880092722 from 2009. We should have less risk
of hitting bugs at this point because we auto-generate positive CHECK
lines only, but this makes things consistent.

Copying the original commit msg:
"Change tests from "opt %s" to "opt < %s" so that opt doesn't see the
input filename so that opt doesn't print the input filename in the
output so that grep lines in the tests don't unintentionally match
strings in the input filename."

show more ...

[InstCombine] foldICmpBinOp(): consider inverted check in 'unsigned sub overflow' check

A follow-up for r329011.
This may be changed to produce @llvm.sub.with.overflow in a later patch,
but for now

[InstCombine] foldICmpBinOp(): consider inverted check in 'unsigned sub overflow' check

A follow-up for r329011.
This may be changed to produce @llvm.sub.with.overflow in a later patch,
but for now just make things more consistent overall.

A few observations stem from this:
* There does not seem to be a similar one-instruction fold for uadd-overflow
* I'm not sure we'll want to canonicalize `B u> A` as `usub.with.overflow`,
so since the `icmp` here no longer refers to `sub`,
reconstructing `usub.with.overflow` will be problematic,
and will likely require standalone pass (similar to DivRemPairs).

https://rise4fun.com/Alive/Zqs

Name: (A - B) u> A --> B u> A
%t0 = sub i8 %A, %B
%r = icmp ugt i8 %t0, %A
=>
%r = icmp ugt i8 %B, %A

Name: (A - B) u<= A --> B u<= A
%t0 = sub i8 %A, %B
%r = icmp ule i8 %t0, %A
=>
%r = icmp ule i8 %B, %A

Name: C u< (C - D) --> C u< D
%t0 = sub i8 %C, %D
%r = icmp ult i8 %C, %t0
=>
%r = icmp ult i8 %C, %D

Name: C u>= (C - D) --> C u>= D
%t0 = sub i8 %C, %D
%r = icmp uge i8 %C, %t0
=>
%r = icmp uge i8 %C, %D

llvm-svn: 371101

show more ...

[InstCombine][NFC] Tests for 'unsigned sub overflow' check

----------------------------------------
Name: unsigned sub, overflow, v0
%sub = sub i8 %x, %y
%ov = icmp ugt i8 %sub, %x
=>
%agg = u

[InstCombine][NFC] Tests for 'unsigned sub overflow' check

----------------------------------------
Name: unsigned sub, overflow, v0
%sub = sub i8 %x, %y
%ov = icmp ugt i8 %sub, %x
=>
%agg = usub_overflow i8 %x, %y
%sub = extractvalue {i8, i1} %agg, 0
%ov = extractvalue {i8, i1} %agg, 1

Done: 1
Optimization is correct!

----------------------------------------
Name: unsigned sub, no overflow, v0
%sub = sub i8 %x, %y
%ov = icmp ule i8 %sub, %x
=>
%agg = usub_overflow i8 %x, %y
%sub = extractvalue {i8, i1} %agg, 0
%not.ov = extractvalue {i8, i1} %agg, 1
%ov = xor %not.ov, -1

Done: 1
Optimization is correct!

llvm-svn: 371099

show more ...