[llvm-dev] Implementing a proposed InstCombine optimization

[via llvm-dev]

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] 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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160412/966f111f/attachment.html>