[LLVMdev] Optimization of sqrt() with invalid argument

Mon Sep 29 10:16:00 PDT 2014

Thanks for the pointer, James.

The consensus then and now appears to be that we should generate undef
rather than 0.0.
Patch proposal here:
http://reviews.llvm.org/D5527

It was also suggested that the front-end emit a warning for code that is
clearly invoking undefined behavior:
http://llvm.org/bugs/show_bug.cgi?id=21093

On Mon, Sep 29, 2014 at 3:19 AM, James Molloy <James.Molloy at arm.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140929/3a61f1a0/attachment.html>