-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Missed optimization: dead code is not eliminated based on possible floating-point values at any optimization level. #82381
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
Comments
Currently we don't have a plan to eliminate fcmps based on ranges. |
I see. I bet adding support like this would take a pretty big effort if the constraint system is designed around integers. However, It seems like something to keep on the table for the future. Bounds-checking situations like the one described above can produce a decent amount of unneeded overhead especially for code that enforces many constraints on values. |
@nikic What do you think of handling some trivial cases with Anyway we should implement ConstantRangeFP first. |
Just curious. I might not know the C++ language well, but isn't it dangerous to optimize out that exception throw when the If I remember correctly, |
Floating point exceptions aren't exceptions in the C++ sense. The invalid operation exception would be raised if there was a signaling nan, but you have to enable fenv access for that |
@arsenm I was referring to a quiet NaN in a C++ context. Even though comparing with an |
We cannot do the optimization if |
Update. It seems that the OP used the "-Ofast" option in the godbolt link (https://godbolt.org/z/6sWTPvne9), which implied "-ffast-math" and that we don't need to care about NaN case. But generally the optimization proposed is unsafe, as we need to keep the IEEE behavior regarding NaNs. |
Yes. I did consider the nuances of IEEE floats like this, and nans do cause an issue with such an optimization. I probably should have made that more clear earlier on that only fast math modes would apply for an optimization like this. In fast math mode contexts where IEEE behaviors are not required though, it should still be possible to do something. |
https://godbolt.org/z/6sWTPvne9
The text was updated successfully, but these errors were encountered: