[PATCH] D47747: [LangRef] Clarify "undefined" for various instructions.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added inline comments.


================
Comment at: docs/LangRef.rst:4956
+returned by the called function at this call site is in. If the loaded or
+returned value is not in the specified range, the behavior is undefined. The
+ranges are represented with a flattened list of integers. The loaded value or
----------------
nlopes wrote:
> UB vs poison here:
>  - UB: after a load with 'range' we know the memory has a value within the range.
>  - Poison: after branching on the loaded value we know the memory as a value within the range.
> 
> UB has more imediate effects than poison, of course. For GVN and friends, UB is a bit easier, but hoisting such an instruction we need to drop the range metadata. Is it done today?
> For range analysis, I guess both semantics are fine, though the UB semantics may potentially allow a better analysis since after the load the analysis can assume the range right away instead of waiting for a branch.  The UB semantics helps shrinking bitwidth of arithmetic as well, which otherwise isn't easy to do (since you would need to check the users of the expression tree).
> 
> Bottom line: this really depends on what kind of transformations LLVM does today (and in the future) that care about this range metadata.
> 
AFAIK GVN and friends use the combineMetadata helper to set the metadata of a instruction K replacing an instruction J. Currently this function only sets metadata like !range and !nonnull if both instructions have them (for range it selects the most general range). With using UB here (and for nonnull) we should be able to preserve such metadata kinds in K if it dominates J, as in D47339 and D47475


Repository:
  rL LLVM

https://reviews.llvm.org/D47747