[all-commits] [llvm/llvm-project] 61580d: Reapply [InstCombine] Remove one-use limitation fr...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 61580d0949fd3465f53c71f5a8f304d4722a38fb
      https://github.com/llvm/llvm-project/commit/61580d0949fd3465f53c71f5a8f304d4722a38fb
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2022-03-02 (Wed, 02 Mar 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
    M llvm/test/Transforms/InstCombine/icmp-sub.ll
    M llvm/test/Transforms/InstCombine/prevent-cmp-merge.ll
    M llvm/test/Transforms/InstCombine/result-of-usub-is-non-zero-and-no-overflow.ll

  Log Message:
  -----------
  Reapply [InstCombine] Remove one-use limitation from X-Y==0 fold

This is a recommit without changes. I originally reverted this
due to a significant code-size regression on tramp3d-v4, however
further investigation showed that in the tramp3d-v4 case this
change enables additional optimizations (in particular more
jump threading), which happens to reduce the size of a function
just enough to be eligible for inlining at hot callsites, which
results in the code size increase. As such, this was just bad
luck.

-----

This one-use limitation is artificial, we do not increase
instruction count if we perform the fold with multiple uses. The
motivating case is shown in @sub_eq_zero_select, where the one-use
limitation causes us to miss a subsequent select fold.

I believe the backend is pretty good about reusing flag-producing
subs for cmps with same operands, so I think doing this is fine.

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