[all-commits] [llvm/llvm-project] 0db5d8: Reapply [InstSimplify] Make simplifyWithOpReplaced...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0db5d8e12384d780d2ded6b972233dc8b1632560
      https://github.com/llvm/llvm-project/commit/0db5d8e12384d780d2ded6b972233dc8b1632560
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2023-07-18 (Tue, 18 Jul 2023)

  Changed paths:
    M llvm/lib/Analysis/InstructionSimplify.cpp
    M llvm/test/Transforms/InstCombine/div-by-0-guard-before-smul_ov-not.ll
    M llvm/test/Transforms/InstCombine/div-by-0-guard-before-umul_ov-not.ll
    M llvm/test/Transforms/InstCombine/select-ctlz-to-cttz.ll
    M llvm/test/Transforms/InstCombine/shift.ll
    M llvm/test/Transforms/InstSimplify/select.ll

  Log Message:
  -----------
  Reapply [InstSimplify] Make simplifyWithOpReplaced() recursive (PR63104)

A similar assumption as for the x^x case also existed for the absorber
case, which lead to a stage2 miscompile. That assumption is not fixed.

-----

Support replacement of operands not only in the immediate
instruction, but also instructions it uses.

To the most part, this extension is straightforward, but there are
two bits worth highlighting:

First, we can now no longer assume that if the Op is a vector, the
instruction also returns a vector. If Op is a vector and the
instruction returns a scalar, we should consider it as a cross-lane
operation.

Second, for the x ^ x special case and the absorber special case, we
can no longer assume that one of the operands is RepOp, as we might
have a replacement higher up the instruction chain.

There is one optimization regression, but it is in a fuzzer-generated
test case.

Fixes https://github.com/llvm/llvm-project/issues/63104.