[LLVMdev] Optimization of sqrt() with invalid argument

Bill Schmidt wschmidt at linux.vnet.ibm.com
Fri Sep 26 11:23:16 PDT 2014


On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote:
> > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> > 
> >> I know it's part of test-suite/external, but this constant fold code has
> >> been around 5+ years. Was the bug lying dormant all this time, only visible
> >> on PPC, or something else?
> > 
> > My guess would be that people don't tend to run with -ffast-math (it's
> > got a reputation for breaking code, even ignoring this particular
> > issue). Without that, from what I can see the issue won't arise.
> 
> If this can really only happen under fast-math, I take back what I said entirely.  IIRC, NaNs are explicitly not supported in that mode, so all bets are off.  Zero is a perfectly reasonable result.

The result of this is that we return 0 only under -ffast-math.  In all
other cases, the sqrt call will remain and we will return NaN.  So that
seems like a bothersome discrepancy given that the Posix standard
wording tends to favor NaN (though an implementation-defined value is
allowable, regardless of -ffast-math).

As mentioned earlier, a number of other compilers also generate NaN with
-ffast-math or its equivalent.  I believe this is done to comply with
the Posix wording.

Regardless of feelings about playing benchmark games (with which I have
sympathy), people tend to compile many of the SPECfp benchmarks with
-ffast-math so they can, e.g., use FMA instructions in their publishes.
But this is a side issue, and I'm rather sorry I mentioned SPEC at all.
This is really an issue of internal and external consistency.

Thanks,
Bill

> 
> – Steve





More information about the llvm-dev mailing list