[PATCH] D76973: [LangRef] Clarify the semantics of branch on undef

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 28 12:22:37 PDT 2020


nlopes added inline comments.


================
Comment at: llvm/docs/LangRef.rst:3457
+a not-frozen expression containing undef and it can be evaluted into different
+values.
+This explains optimizations that depend on branch conditions to construct
----------------
aqjune wrote:
> nikic wrote:
> > This definition seems unnecessary confusing, just saying "Branching on undef is undefined behavior" should be sufficient here. Undef is not frozen by definition. There's also no meaningful concept of "contains undef" in this context, as branch conditions are always scalar, so the value can only be undef or not be undef. Expressions reduce to undef or not undef in the usual ways.
> The tricky case is when a partially undef (e.g. `undef | 1`) is given to switch.
> I rephrased the text to make it clear that switching on a value is UB if it is not frozen. This needed defining the notion of a frozen value above.
Undef is a non-deterministic value that can evaluate to different values each time it is used, while "freeze undef" cannot.
That's the main difference. The way to detect this is to say that if the expression we branch on can evaluate to both true and false given the current state then it's UB.
Not sure we need to make this so explicit. Alive2 already has the details implemented.

BTW, @aqjune can you post the examples of optimizations that are incorrect if "br undef" is UB that I wrote the other day. Sorry, I don't have that email here at hand.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76973





More information about the llvm-commits mailing list