[PATCH] D139314: ValueTracking: Teach canCreateUndefOrPoison about FP ops

[Aaron Ballman via Phabricator via llvm-commits]

aaron.ballman added inline comments.


================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:5239
+      case Intrinsic::llrint:
+        // If the value doesn't fit an unspecified value is returned.
+        break;
----------------
nlopes wrote:
> aaron.ballman wrote:
> > aqjune wrote:
> > > Actually this part is slightly tricky, I think.
> > > In C++ an unspecified value is a well-defined value meaning that its usage does not introduce UB unless the operation is supposed to do so.
> > > This is different from undefined value or poison value because their usage may introduce UB.
> > > Therefore, I think we can say that `canCreateUndefOrPoison` can return `false` for these ops.
> > > I would like to cross-check my understanding with clang - @aaron.ballman May I ask whether my understanding is correct please?
> > > I would like to cross-check my understanding with clang - @aaron.ballman May I ask whether my understanding is correct please?
> > 
> > You're correct.
> > 
> > C2x 7.12.9.5p2: The lrint and llrint functions round their argument to the nearest integer value, rounding according to the current rounding direction. If the rounded value is outside the range of the return type, the numeric result is unspecified and a domain error or range error may occur.
> > 
> > C2x 3.19.3p1: unspecified value -- valid value of the relevant type where this document imposes no requirements on which value is chosen in any instance.
> > 
> > C2x 3.4.4p1: unspecified behavior -- behavior, that results from the use of an unspecified value, or other behavior upon which this
> > document provides two or more possibilities and imposes no further requirements on which is chosen in any instance.
> > 
> > The only assumption the optimizer is allowed to make about an unspecified value is that the object holds an arbitrary value that may change on any given access.
> > the numeric result is unspecified
> 
> Doesn't say unspecified value, only unspecified.
> Are we sure that means the same?
> 
> Alive2 models this condition as poison FWIW, and I'm afraid LLVM might be taking advantage of that.
> 
>> the numeric result is unspecified
> Doesn't say unspecified value, only unspecified.
> Are we sure that means the same?

Yes, they mean the same thing. Functions return values, this returned value is unspecified, so it's an unspecified value.


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

https://reviews.llvm.org/D139314