<div dir="ltr"><div><div><div>Thanks for the pointer, James.<br></div><br>The consensus then and now appears to be that we should generate undef rather than 0.0.<br></div>Patch proposal here:<br><a href="http://reviews.llvm.org/D5527">http://reviews.llvm.org/D5527</a><br><br></div>It was also suggested that the front-end emit a warning for code that is clearly invoking undefined behavior:<br><a href="http://llvm.org/bugs/show_bug.cgi?id=21093">http://llvm.org/bugs/show_bug.cgi?id=21093</a><br><br><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 3:19 AM, James Molloy <span dir="ltr"><<a href="mailto:James.Molloy@arm.com" target="_blank">James.Molloy@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
This was brought up by Jiangning back in June:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/220598
.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/220598<br>
.html</a><br>
<br>
In that thread, Tim was pushing very hard that NaN is not categorically<br>
better than 0.0, and that we shouldn't have to replicate GCC's undefined<br>
behaviour.<br>
<br>
The outcome of that thread is that we use -fno-fast-math for xalancbmk in<br>
Spec2k6, which is what it sounds like the IBM guys will have to do. It'd<br>
be nice if we didn't have to do that , but I don't disagree with any of<br>
the arguments in the original thread.<br>
<br>
Cheers,<br>
<br>
James<br>
<div><div class="h5"><br>
On 28/09/2014 02:53, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
<br>
>----- Original Message -----<br>
>> From: "Sanjay Patel" <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>><br>
>> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
>> Cc: "Bill Schmidt" <<a href="mailto:wschmidt@linux.vnet.ibm.com">wschmidt@linux.vnet.ibm.com</a>>,<br>
>><a href="mailto:spatel%2Bllvm@rotateright.com">spatel+llvm@rotateright.com</a>, "Will Schmidt"<br>
>> <<a href="mailto:will_schmidt@vnet.ibm.com">will_schmidt@vnet.ibm.com</a>>, "LLVM Developers Mailing List"<br>
>><<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>>, "Stephen Canon"<br>
>> <<a href="mailto:scanon@apple.com">scanon@apple.com</a>><br>
>> Sent: Friday, September 26, 2014 2:03:01 PM<br>
>> Subject: Re: [LLVMdev] Optimization of sqrt() with invalid argument<br>
>><br>
>><br>
>><br>
>><br>
>> This isn't purely a fast-math issue...ConstantFolding isn't using<br>
>> enable-unsafe-fp-math to decide whether to emit the '0'. It's just<br>
>> looking for the llvm intrinsic rather than a call to sqrt:<br>
>><br>
>> %0 = call double @llvm.sqrt.f64(double -2.000000e+00)<br>
>><br>
>> vs:<br>
>><br>
>> %0 = call double @sqrt(double -2.000000e+00) #2<br>
>><br>
>> So how about a front-end fix:<br>
>> If the parameter is a negative constant, instead of converting the<br>
>> sqrt call into the intrinsic, just leave it as-is regardless of<br>
>> fast-math. I think that change would provide internal and external<br>
>> consistency. And I suspect this is the solution the other compilers<br>
>> have reached - they end up generating a HW sqrt instruction even<br>
>> though they could have precomputed the result.<br>
><br>
>I don't think this makes sense (as someone else also said), however, a<br>
>frontend warning seems quite useful.<br>
><br>
> -Hal<br>
><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Sep 26, 2014 at 12:36 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
>> wrote:<br>
>><br>
>><br>
>> ----- Original Message -----<br>
>> > From: "Bill Schmidt" < <a href="mailto:wschmidt@linux.vnet.ibm.com">wschmidt@linux.vnet.ibm.com</a> ><br>
>><br>
>><br>
>> > To: "Stephen Canon" < <a href="mailto:scanon@apple.com">scanon@apple.com</a> ><br>
>> > Cc: <a href="mailto:spatel%2Bllvm@rotateright.com">spatel+llvm@rotateright.com</a> , "Will Schmidt" <<br>
>> > <a href="mailto:will_schmidt@vnet.ibm.com">will_schmidt@vnet.ibm.com</a> >, "LLVM Developers Mailing List"<br>
>> > < <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a> ><br>
>> > Sent: Friday, September 26, 2014 1:23:16 PM<br>
>> > Subject: Re: [LLVMdev] Optimization of sqrt() with invalid argument<br>
>> ><br>
>> > On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote:<br>
>> > > > On Sep 26, 2014, at 11:59 AM, Tim Northover<br>
>> > > > < <a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a> > wrote:<br>
>> > > ><br>
>> > > >> I know it's part of test-suite/external, but this constant<br>
>> > > >> fold<br>
>> > > >> code has<br>
>> > > >> been around 5+ years. Was the bug lying dormant all this time,<br>
>> > > >> only visible<br>
>> > > >> on PPC, or something else?<br>
>> > > ><br>
>> > > > My guess would be that people don't tend to run with<br>
>> > > > -ffast-math<br>
>> > > > (it's<br>
>> > > > got a reputation for breaking code, even ignoring this<br>
>> > > > particular<br>
>> > > > issue). Without that, from what I can see the issue won't<br>
>> > > > arise.<br>
>> > ><br>
>> > > If this can really only happen under fast-math, I take back what<br>
>> > > I<br>
>> > > said entirely. IIRC, NaNs are explicitly not supported in that<br>
>> > > mode, so all bets are off. Zero is a perfectly reasonable result.<br>
>> ><br>
>> > The result of this is that we return 0 only under -ffast-math. In<br>
>> > all<br>
>> > other cases, the sqrt call will remain and we will return NaN. So<br>
>> > that<br>
>> > seems like a bothersome discrepancy given that the Posix standard<br>
>> > wording tends to favor NaN (though an implementation-defined value<br>
>> > is<br>
>> > allowable, regardless of -ffast-math).<br>
>> ><br>
>> > As mentioned earlier, a number of other compilers also generate NaN<br>
>> > with<br>
>> > -ffast-math or its equivalent. I believe this is done to comply<br>
>> > with<br>
>> > the Posix wording.<br>
>> ><br>
>> > Regardless of feelings about playing benchmark games (with which I<br>
>> > have<br>
>> > sympathy), people tend to compile many of the SPECfp benchmarks<br>
>> > with<br>
>> > -ffast-math so they can, e.g., use FMA instructions in their<br>
>> > publishes.<br>
>> > But this is a side issue, and I'm rather sorry I mentioned SPEC at<br>
>> > all.<br>
>> > This is really an issue of internal and external consistency.<br>
>><br>
>> Yes, but Steve is right: -ffast-math implies -ffinite-math-only,<br>
>> which means that we assume no NaNs. I understand that people use<br>
>> -ffast-math to get vectorized reductions (just getting aggressive<br>
>> FMAs only requires -ffp-contract=fast), but this, unfortunately, is<br>
>> also a matter of internal consistency :(<br>
>><br>
>> -Hal<br>
>><br>
>> ><br>
>> > Thanks,<br>
>> > Bill<br>
>> ><br>
>> > ><br>
>> > > Steve<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
>><br>
>> ><br>
>><br>
>> --<br>
>> Hal Finkel<br>
>> Assistant Computational Scientist<br>
>> Leadership Computing Facility<br>
>> Argonne National Laboratory<br>
>><br>
>><br>
><br>
>--<br>
>Hal Finkel<br>
>Assistant Computational Scientist<br>
>Leadership Computing Facility<br>
>Argonne National Laboratory<br>
><br>
>_______________________________________________<br>
>LLVM Developers mailing list<br>
><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
</div></div>-- 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.<br>
<br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590<br>
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782<br>
<br>
</blockquote></div><br></div>