Probably could replace the switch by marking the intrinsic definitions
with NoUndef<RetIndex>.
Details
- Reviewers
nlopes aqjune jcranmer-intel spatel
Diff Detail
Event Timeline
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
5250 | Actually this part is slightly tricky, I think. |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
5250 |
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 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. |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
5250 |
Doesn't say unspecified value, only unspecified. Alive2 models this condition as poison FWIW, and I'm afraid LLVM might be taking advantage of that. |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
5250 |
Yes, they mean the same thing. Functions return values, this returned value is unspecified, so it's an unspecified value. |
Should I mention this doesn't produce poison in LangRef?
I also think it's extremely broken that we have both lround and llround (same with rint). Why isn't this one overloaded intrinsic? Why did it blindly copy the libm's i-don't-know-how-big-integers-are naming?
I checked the updated instructions' LLVM LangRef documentation as well as cppreference.com description and they looked good to me
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?