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

[Aldy Hernandez <aldyh@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

I wonder if instead of disabling ranger altogether, we could disable code
changes (constant propagation, jump threading and simplify_using_ranges)?
Or does that sound like too much hassle?

It seems that some passes (instruction selection?) could benefit from
global ranges being available even if no propagation was done.

Just a thought. I don't have strong opinions here.

Aldy

On Fri, Nov 18, 2022, 12:20 Aldy Hernandez <aldyh@redhat.com> wrote:

>
>
> 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
>