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)?
Jakub
