[PATCH] D93065: [InstCombine] Disable optimizations of select instructions that causes propagation of poison values

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D93065#2472631 <https://reviews.llvm.org/D93065#2472631>, @aqjune wrote:

> I wanted to make ScalarEvolution recognize select pattern, and became a bit uncertain about its validity.
>
> Take this example: https://alive2.llvm.org/ce/z/NsP9ue
> SCEV's computeExitLimit can return min(n, m) as ExactNotTaken value, so I put llvm.assume to show its validity.
> But it fails because the exit limit becomes poison if n is zero and m is poison. This will make e.g. replacing the last value of i with min(n, m) invalid.
> If `and` is used instead, this becomes okay: https://alive2.llvm.org/ce/z/K9rbJk
>
> If there is a guard about n and m at the loop header it would be safe I think. Is this what SCEV assumes? Then, how should the input look like?

I think you are right about this. SCEV doesn't really have the facilities to represent this. I think the only thing we can do at the SCEV level is to at least determine that the first condition implies an upper bound, even if we can't use the second one. Guess this is more motivation to try fairly hard to convert select -> and/or for the cases where we can do so.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93065/new/

https://reviews.llvm.org/D93065