[LLVMdev] Optimization of sqrt() with invalid argument

Hal Finkel hfinkel at anl.gov
Fri Sep 26 11:36:07 PDT 2014


----- Original Message -----
> From: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>
> To: "Stephen Canon" <scanon at apple.com>
> Cc: spatel+llvm at rotateright.com, "Will Schmidt" <will_schmidt at vnet.ibm.com>, "LLVM Developers Mailing List"
> <llvmdev at cs.uiuc.edu>
> Sent: Friday, September 26, 2014 1:23:16 PM
> Subject: Re: [LLVMdev] Optimization of sqrt() with invalid argument
> 
> 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.

Yes, but Steve is right: -ffast-math implies -ffinite-math-only, which means that we assume no NaNs. I understand that people use -ffast-math to get vectorized reductions (just getting aggressive FMAs only requires -ffp-contract=fast), but this, unfortunately, is also a matter of internal consistency :(

 -Hal

> 
> Thanks,
> Bill
> 
> > 
> > – Steve
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory




More information about the llvm-dev mailing list