-
Notifications
You must be signed in to change notification settings - Fork 15.5k
RuntimeLibcalls: Add mustprogress to common function attributes #167080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RuntimeLibcalls: Add mustprogress to common function attributes #167080
Conversation
31b8490 to
e551019
Compare
47b2103 to
238ad7d
Compare
e551019 to
9b770d3
Compare
ad1d7cb to
b7cc28e
Compare
9b770d3 to
abbd23c
Compare
b7cc28e to
ddc5a54
Compare
06269dd to
abf1fe1
Compare
ddc5a54 to
22df2fb
Compare
|
ping |
RKSimon
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - but I don't know all the idiosyncrasies of mustprogress tbh, but the language reference suggests this should be fine.
These are floating-point functions recorded in TargetLibraryInfo, but missing from RuntimeLibcalls.
These were in TargetLibraryInfo, but missing from RuntimeLibcalls. This only adds the cases that already have the non-chk variants already. Copies the enabled-by-default logic from TargetLibraryInfo, which is probably overly permissive. Only isPS opts-out.
22df2fb to
a921be6
Compare
abf1fe1 to
65e64a8
Compare
|
I'm confused by this change -- why are we adding mustprogress? For intrinsics |
These aren't intrinsics, they're libcall function declarations? |
Same thing. The purpose of mustprogress is to allow inferring willreturn. It is not useful for declarations that are willreturn anyway. The PR has no description, can you please explain what the motivation here was? |

No description provided.