[llvm-dev] Implementing a proposed InstCombine optimization
Daniel Sanders via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 12 09:18:13 PDT 2016
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/9df355b9/attachment.html>
More information about the llvm-dev
mailing list