Re: [PATCH] [range-ops] Implement sqrt.

[Jakub Jelinek <jakub@redhat.com>]

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