[llvm-dev] Implementing a proposed InstCombine optimization

[Daniel Sanders via llvm-dev]

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<mailto: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> [mailto:fglaser at apple.com] On Behalf Of escha at apple.com<mailto: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/d4175987/attachment.html>