This is an archive of the discontinued LLVM Phabricator instance.

ValueTracking: Teach canCreateUndefOrPoison about FP ops
ClosedPublic

Authored by arsenm on Dec 5 2022, 5:24 AM.

Details

Summary

Probably could replace the switch by marking the intrinsic definitions
with NoUndef<RetIndex>.

Diff Detail

Event Timeline

arsenm created this revision.Dec 5 2022, 5:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 5 2022, 5:24 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
arsenm requested review of this revision.Dec 5 2022, 5:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 5 2022, 5:24 AM
Herald added a subscriber: wdng. · View Herald Transcript
aqjune added inline comments.
llvm/lib/Analysis/ValueTracking.cpp
5250

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?

aaron.ballman added inline comments.Dec 5 2022, 9:13 AM
llvm/lib/Analysis/ValueTracking.cpp
5250

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.

nlopes added inline comments.Dec 5 2022, 9:25 AM
llvm/lib/Analysis/ValueTracking.cpp
5250

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.

aaron.ballman added inline comments.Dec 5 2022, 9:30 AM
llvm/lib/Analysis/ValueTracking.cpp
5250

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.

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?

Should I mention this doesn't produce poison in LangRef?

https://reviews.llvm.org/D139349

arsenm updated this revision to Diff 480173.Dec 5 2022, 11:16 AM

Change handling of lround/lrint

aqjune accepted this revision.Dec 12 2022, 10:43 AM

I checked the updated instructions' LLVM LangRef documentation as well as cppreference.com description and they looked good to me

This revision is now accepted and ready to land.Dec 12 2022, 10:43 AM