[llvm-dev] Implementing a proposed InstCombine optimization
Owen Anderson via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 11 14:57:26 PDT 2016
> On Apr 11, 2016, at 1:25 PM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> On Apr 11, 2016, at 12:55 PM, via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 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
>> 126.96.36.199 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.
> [The language frontend plus runtime plus] LLVM is the "implementation”. LLVM can define fneg to be a pure signbit operation if we choose to do so.
> Also, there are no non-canonical encodings in binary16, binary32, or binary64, which I believe are what is under discussion on that thread.
What about platforms that flush denorms? This change could cause the denorm to be flushed, where it wasn’t before.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev