[PATCH] D151691: Revert "[InstCombine] Handle undef when pruning unreachable code"

Tue May 30 04:11:00 PDT 2023

nikic added a comment.

In D151691#4380437 <https://reviews.llvm.org/D151691#4380437>, @tsymalla wrote:

> In D151691#4380433 <https://reviews.llvm.org/D151691#4380433>, @nikic wrote:
>
>> In D151691#4380422 <https://reviews.llvm.org/D151691#4380422>, @tsymalla wrote:
>>
>>> In D151691#4380411 <https://reviews.llvm.org/D151691#4380411>, @nikic wrote:
>>>
>>>> Branch on undef is undefined behavior, see https://llvm.org/docs/LangRef.html#id33:
>>>>
>>>>> If ‘cond’ is poison or undef, this instruction has undefined behavior.
>>>>
>>>> Either your source program has undefined behavior, or some optimization incorrectly introduced the branch on undef. If the latter, you may want to look through the print-after-all trace to identify when the br undef first appears. It's possible that some optimization is failing to `freeze` the condition.
>>>
>>> I know branching and switching on undefs is undefined behavior, and I know that the undef branch is intended. In no way the whole loop as marked in the pseudo-code should be optimized away.
>>
>> I don't understand, why should the loop not be optimized away? Can you maybe provide a failing alive2 proof for the case you have in mind?
>
> In the above pseudo-code, which is the input into some of LLVMs generic passes, the store is executed at least once, independent of the inner branching that either breaks or does not break the loop.
> That's what the final IR without your patch also resembles - it executes the store and does not loop.

I see. Whether the store will be dropped should depend on intrinsic attributes -- which intrinsic is doing the store in this case?

If the intrinsic is willreturn, then UB can propagate upwards past the store. The intrinsic needs to be non-willreturn if it should be retained in such a case.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151691