[LLVMdev] Optimization of sqrt() with invalid argument

[James Molloy]

Hi all,

This was brought up by Jiangning back in June:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/220598
.html

In that thread, Tim was pushing very hard that NaN is not categorically
better than 0.0, and that we shouldn't have to replicate GCC's undefined
behaviour.

The outcome of that thread is that we use -fno-fast-math for xalancbmk in
Spec2k6, which is what it sounds like the IBM guys will have to do. It'd
be nice if we didn't have to do that , but I don't disagree with any of
the arguments in the original thread.

Cheers,

James

On 28/09/2014 02:53, "Hal Finkel" <hfinkel at anl.gov> wrote:

>----- 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
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782