[all-commits] [llvm/llvm-project] e2c698: [InstCombine] Fix miscompilation in `sinkNotIntoLo...

[Yingwei Zheng via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e2c698c7e836306f1a25c67597ae9e25a1fcc575
      https://github.com/llvm/llvm-project/commit/e2c698c7e836306f1a25c67597ae9e25a1fcc575
  Author: Yingwei Zheng <dtcxzyw2333 at gmail.com>
  Date:   2025-06-04 (Wed, 04 Jun 2025)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
    A llvm/test/Transforms/InstCombine/pr142518.ll

  Log Message:
  -----------
  [InstCombine] Fix miscompilation in `sinkNotIntoLogicalOp` (#142727)

Consider the following case:
```
define i1 @src(i8 %x) {
  %cmp = icmp slt i8 %x, -1
  %not1 = xor i1 %cmp, true
  %or = or i1 %cmp, %not1
  %not2 = xor i1 %or, true
  ret i1 %not2
}
```
`sinkNotIntoLogicalOp(%or)` calls `freelyInvert(%cmp,
/*IgnoredUser=*/%or)` first. However, as `%cmp` is also used by `Op1 =
%not1`, the RHS of `%or` is set to `%cmp.not = xor i1 %cmp, true`. Thus
`Op1` is out of date in the second call to `freelyInvert`. Similarly,
the second call may change `Op0`. According to the analysis above, I
decided to avoid this fold when one of the operands is also a user of
the other.

Closes https://github.com/llvm/llvm-project/issues/142518.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications