On Thu, 27 Apr 2023, Jakub Jelinek wrote: > On Thu, Apr 27, 2023 at 07:18:52AM +0000, Richard Biener wrote: > > Humm. Is it worth the trouble? I think if we make use of this it needs > > I think so. Without that, frange is half blind, using at least most common > libm functions in floating point code is extremely common and without > knowing anything about what those functions can or can't return frange will > be mostly VARYING. And simply assuming all libm implementations are perfect > 0.5ulps precise for all inputs would be very risky when we know it clearly > is not the case. > > Of course, by improving frange further, we run more and more into the > already reported and just tiny bit worked around bug on the optimized away > floating point exception generating statements and we need to decide what to > do for that case.. > > > to be with -funsafe-math-optimizations (or a new switch?). I'll note > > Why? If we know or can reasonably assume that say on the boundary values > some function is always precise (say sqrt always in [-0.,+Inf] U NAN, > sin/cos always in [-1.,1.] U NAN etc., that isn't an unsafe math > optimization to assume it is the case. If we know it is a few ulps away > from that, we can just widen the range, if we don't know anything or the > function implementation is uselessly buggy, we can punt. > Whether something is a known math library function or just some floating > point arithmetics which we already handle in 13.1 shouldn't make much > difference.
OK, fair enough. > > Should we, when simplifying say > > > > x = sin (y); > > if (x <= 1.) > > > > simplify it to > > > > x = sin (y); > > x = min (x, 1.); > > > > for extra safety? > > Why? If we don't know anything about y, x could be NAN, so we can't fold > it, but if we know it will not be NAN, it is always true and we are there > back to the exceptions case (plus errno but that makes the function > non-const, doesn't it?). > > > That said - what kind of code do we expect to optimize when producing > > ranges for math function [operands]? Isn't it just defensive programming > > that we'd "undo"? Are there any missed-optimization PRs around this? > > I strongly doubt real-world code has such defensive programming checks. > The intent isn't to optimize those away, but generally propagate range > information, such that we say know that sqrt result isn't negative (except > for possible -0. or negative NaN), when you add sin(x)^2+cos(y)^2 it will be > never > 2. etc. > It can then e.g. help with expansion of other possibly error generating > functions, e.g. where cdce transforms library function calls into inline > fast hw instruction vs. slow libm function for error cases; if we can prove > those error cases will never happen or will always happen, we can create > smaller/faster code. OK. As said the patch itself looks good to me, let's go ahead. We have plenty of time to backtrack until GCC 14. Richard.
