thr3ads.net - llvm dev - [LLVMdev] Optimization of sqrt() with invalid argument [Sep 2014]

If this information is useful, please help other people find it:
Share via:

Sanjay Patel

2014-Sep-26 19:03 UTC

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


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

Tim Northover

2014-Sep-26 19:20 UTC

head link

[LLVMdev] Optimization of sqrt() with invalid argument

On 26 September 2014 12:03, Sanjay Patel <spatel at rotateright.com>
wrote:> 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:
Yep. As Hal said, the key option is -ffinite-math, which allows the
front-end to emit that intrinsic in the first place. We document
@llvm.sqrt's behaviour and it has no requirements to check
unsafe-fp-math before folding.
> 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.
That sounds like a nasty hack to me. It covers only a very limited set
of situations where this would happen. For example, almost certainly
not:

double foo() {
  const double x = -1.0;
  return sqrt(x);
}

Possibly not even (depending on how you define "constant"):

    double foo() { return sqrt(-1.0f); }

If we're going to change it I'd prefer the active decision in the
mid-end.

Cheers.

Tim.

Sanjay Patel

2014-Sep-26 19:43 UTC

head link

[LLVMdev] Optimization of sqrt() with invalid argument

Yeah, it's a hack. I was just hoping to let everyone walk away a winner. :)

One more question then:
Why return zero instead of undef?

          if (V >= -0.0)
            return ConstantFoldFP(sqrt, V, Ty);
          else // Undefined
            return Constant::getNullValue(Ty);

Surely returning UndefValue::get(Ty) would allow greater havoc to ensue?
Maybe even the segfault that you suggested. :)

I don't think clang emits any warnings for the bogus C code...that would be
the nicer thing to do.

On Fri, Sep 26, 2014 at 1:20 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 26 September 2014 12:03, Sanjay Patel <spatel at rotateright.com>
wrote:
> > 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:
>
> Yep. As Hal said, the key option is -ffinite-math, which allows the
> front-end to emit that intrinsic in the first place. We document
> @llvm.sqrt's behaviour and it has no requirements to check
> unsafe-fp-math before folding.
>
> > 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.
>
> That sounds like a nasty hack to me. It covers only a very limited set
> of situations where this would happen. For example, almost certainly
> not:
>
> double foo() {
>   const double x = -1.0;
>   return sqrt(x);
> }
>
> Possibly not even (depending on how you define "constant"):
>
>     double foo() { return sqrt(-1.0f); }
>
> If we're going to change it I'd prefer the active decision in the
mid-end.
>
> Cheers.
>
> Tim.
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140926/9a85fe80/attachment.html>

Hal Finkel

2014-Sep-28 01:53 UTC

head link

[LLVMdev] Optimization of sqrt() with invalid argument

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

James Molloy

2014-Sep-29 09:19 UTC

head link

[LLVMdev] Optimization of sqrt() with invalid argument

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

llvm dev - Sep 2014 - [LLVMdev] Optimization of sqrt() with invalid argument

[LLVMdev] Optimization of sqrt() with invalid argument

[LLVMdev] Optimization of sqrt() with invalid argument

[LLVMdev] Optimization of sqrt() with invalid argument

[LLVMdev] Optimization of sqrt() with invalid argument

[LLVMdev] Optimization of sqrt() with invalid argument