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 <al...@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 >
