[LLVMdev] Optimization of sqrt() with invalid argument

[Bill Schmidt]

On Fri, 2014-09-26 at 13:36 -0500, Hal Finkel 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 :(

Hi Hal,

Sure.  Well, if the consensus is that we don't want to change this, then
so be it -- but I expect I won't be the last person to raise the issue.

At the least, we should constant-fold to NaN for the non fast-math sqrt
calls...there's no point in going through the libcall overhead when we
know the answer in advance.  I can prepare a patch for that if everyone
agrees.

Thanks,
Bill

> 
>  -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
> > 
>