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

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 30 04:00:35 PDT 2023


nikic added a comment.

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?

> What do you mean by "freezing" the condition?

See https://llvm.org/docs/LangRef.html#freeze-instruction. Freezing the condition means that the branch will be non-deterministic rather than undefined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151691



More information about the llvm-commits mailing list