<div dir="ltr"><div><div>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:<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></div>So how about a front-end fix:<br></div>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.<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 12:36 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Bill Schmidt" <<a href="mailto:wschmidt@linux.vnet.ibm.com">wschmidt@linux.vnet.ibm.com</a>><br>
</span><div><div class="h5">> 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" <<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 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 -ffast-math<br>
> > > (it's<br>
> > > got a reputation for breaking code, even ignoring this particular<br>
> > > issue). Without that, from what I can see the issue won't arise.<br>
> ><br>
> > If this can really only happen under fast-math, I take back what 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 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 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 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>
</div></div>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 :(<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>
<div class="HOEnZb"><div class="h5">><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>