Issue 122532
Summary Undef description of branching in LangRef seems ambiguous.
Labels new issue
Assignees
Reporter Chobbes
    In the section on undefined values https://llvm.org/docs/LangRef.html#undefined-values

LangRef provides the following example:

```
  %A = select undef, %X, %Y
  %B = select undef, 42, %Y
  %C = select %X, %Y, undef
Safe:
  %A = %X     (or %Y)
  %B = 42     (or %Y)
  %C = %Y     (if %Y is provably not poison; unsafe otherwise)
Unsafe:
  %A = undef
  %B = undef
  %C = undef
```

And states:

> This set of examples shows that undefined ‘select’ (and conditional branch) conditions can go either way, but they have to come from one of the two operands

Later on in this section, the following is stated:

>Branching on an undefined value is undefined behavior. This explains optimizations that depend on branch conditions to construct predicates, such as Correlated Value Propagation and Global Value Numbering. In case of switch instruction, the branch condition should be frozen, otherwise it is undefined behavior.

The first quote seems to suggest that a conditional branch on `undef` is a non-deterministic jump. The second statement claims that it is in fact UB, unless the `undef` value has been frozen first.

My interpretation of what is meant is the following:

1. `select` instructions don't count as branches, and selecting with an `undef` condition is allowed.
2. Branching on an `undef` value is UB (i.e., if the value represents multiple values, branching on it is UB).

Under this interpretation the first quote isn't necessarily wrong (the program can do anything when UB is encountered, including going down one of the branches), but I assume that isn't the intention, and maybe this should be rephrased to be more clear --- perhaps we should just remove the "(and conditional branch)" part?

Would love to hear what other people think, especially if I'm misunderstanding something!

Thanks!
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to