[LLVMdev] Optimization of sqrt() with invalid argument

[Hal Finkel]

----- Original Message -----
> From: "Sanjay Patel" <spatel at rotateright.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Bill Schmidt" <wschmidt at linux.vnet.ibm.com>, spatel+llvm at rotateright.com, "Will Schmidt"
> <will_schmidt at vnet.ibm.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Stephen Canon"
> <scanon at apple.com>
> Sent: Friday, September 26, 2014 2:03:01 PM
> Subject: Re: [LLVMdev] Optimization of sqrt() with invalid argument
> 
> 
> 
> 
> This isn't purely a fast-math issue...ConstantFolding isn't using
> enable-unsafe-fp-math to decide whether to emit the '0'. It's just
> looking for the llvm intrinsic rather than a call to sqrt:
> 
> %0 = call double @llvm.sqrt.f64(double -2.000000e+00)
> 
> vs:
> 
> %0 = call double @sqrt(double -2.000000e+00) #2
> 
> So how about a front-end fix:
> If the parameter is a negative constant, instead of converting the
> sqrt call into the intrinsic, just leave it as-is regardless of
> fast-math. I think that change would provide internal and external
> consistency. And I suspect this is the solution the other compilers
> have reached - they end up generating a HW sqrt instruction even
> though they could have precomputed the result.

I don't think this makes sense (as someone else also said), however, a frontend warning seems quite useful.

 -Hal

> 
> 
> 
> 
> 
> 
> On Fri, Sep 26, 2014 at 12:36 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> ----- 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
> 
> 

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