[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