[llvm-dev] Implementing a proposed InstCombine optimization

[Sanjay Patel via llvm-dev]

I've proposed to replace the related fabs() instcombine as a DAG combine:
http://reviews.llvm.org/D19391

I still think we should specify what the default FP model is for LLVM, but
this patch will hopefully sidestep failures for denorm-as-zero targets
introduced by the earlier fabs() patch.

On Tue, Apr 12, 2016 at 10:33 AM, Daniel Sanders via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'm just talking about the IEEE754-2008 case in my previous email. You
> mentioned that your target uses arithmetic negation which isn't permitted
> by IEEE754-2008. For arithmetic negation, the optimization is definitely
> unsafe.
>
>
>
> *From:* fglaser at apple.com [mailto:fglaser at apple.com] *On Behalf Of *
> escha at apple.com
> *Sent:* 12 April 2016 17:24
> *To:* Daniel Sanders
> *Cc:* Alex Rosenberg; llvm-dev at lists.llvm.org; Carlos Liam
> *Subject:* Re: [llvm-dev] Implementing a proposed InstCombine optimization
>
>
>
> Keep in mind we had a real GLSL conformance test fail because of exactly
> this sort of “optimization” (using float operations to perform
> non-destructive operations on values that are actually integers).
>
>
>
> —escha
>
>
>
> On Apr 12, 2016, at 9:18 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
>
>
>
> Good point. The same argument seems to apply to copy() too so I suppose it
> depends how strict we want to be about it.
>
>
>
> *From:* fglaser at apple.com [mailto:fglaser at apple.com <fglaser at apple.com>] *On
> Behalf Of *escha at apple.com
> *Sent:* 11 April 2016 20:55
> *To:* Daniel Sanders
> *Cc:* Alex Rosenberg; llvm-dev at lists.llvm.org; Carlos Liam
> *Subject:* Re: [llvm-dev] Implementing a proposed InstCombine optimization
>
>
>
>
>
> On Apr 11, 2016, at 4:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
>
>
>
> > I am not entirely sure this is safe. Transforming this to an fsub could
> change the value stored on platforms that implement negates using
> arithmetic instead of with bitmath (such as ours)
>
>
>
> I think it's probably safe for IEEE754-2008 conformant platforms because
> negation was clarified to be a non-arithmetic bit flip that cannot cause
> exceptions in that specification.
>
>
>
> I did some digging into IEEE-754 and it seems like this is actually not
> even safe on fully conformant IEEE-754-2008 platforms.
>
>
>
> 5.5.1 Sign bit operations
>
> 5.5.1.0 Implementations shall provide the following homogeneous
> quiet-computational sign bit operations for all supported arithmetic
> formats; they only affect the sign bit. The operations treat floating-point
> numbers and NaNs alike, and signal no exception. These operations may
> propagate non-canonical encodings.
>
>
>
> copy(x) copies a floating-point operand x to a destination in the same
> format, with no change to the sign bit.
>
> negate(x) copies a floating-point operand x to a destination in the same
> format, reversing the sign bit. negate(x) is not the same as subtraction(0,
> x) (see 6.3).
>
>
>
> Note the MAY. fneg is required to flip the top bit even if the input is a
> NaN. But fneg is not required to maintain the other bits. If the input is a
> non-canonical NaN, the fneg MAY canonicalize it. In fact, even the ‘copy’
> MAY canonicalize it. (it also MAY choose to not canonicalize it)
>
>
>
> Thus, if the integer being fneg’d is a non-canonical NaN, fneg MAY modify
> bits other than the top bit.
>
>
>
> —escha
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160422/e2765637/attachment-0001.html>