On 11/18/22 11:44, Jakub Jelinek wrote:
On Fri, Nov 18, 2022 at 11:37:42AM +0100, Aldy Hernandez wrote:
Practically strictly
preserving IEEE exceptions is only important for a very small audience, and
for that even INEXACT will matter (but we still have -ftrapping-math
by default).
For that audience likely all constant / range propagation is futile and thus the
easiest thing might be to simply cut that off completely?
I'd say what ranger does is reasonable with -ftrapping-math given the current
practice of handling this option. There's no point in trying to preserve the
(by accident) "better" handling without ranger. Instead as Joseph says somebody
would need to sit down, split -ftrapping-math, adjust the default and thorougly
document things (also with -fnon-call-exceptions which magically makes
IEEE flag raising operations possibly throw exceptions). As there's currently
no code motion barriers for FP code with respect to exception flag inspection
any dead code we preserve is likely going to be unhelpful.
So for now simply amend the documentation as to what -ftrapping-math
currently means with respect to range/constant propagation?
So something like "Even in the presence of -ftrapping-math, VRP may fold
operations that may cause exceptions For example, an addition that is
guaranteed to produce a NAN, may be replaced with a NAN, thus eliding the
addition. This may cause any exception that may have been generated by the
addition to not appear in the final program."
??
If we just adjust user expectations for -ftrapping-math, shouldn't we
introduce another option that will make sure we never optimize away floating
point operations which can trap (and probably just disable frange for that
mode)?
That seems like a big hammer, but sure. We could change
frange::supports_p() to return false for flag_severely_limiting_option :).
Aldy
