[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