[llvm-dev] Implementing a proposed InstCombine optimization

[Matthias Braun via llvm-dev]

I just wanted to stress this for future discussions: One important goal of the intermediate representation is to normalize the program.
If something can be represented by two equivalent IR constructs then in general we should try to choose one variant as normal form and transform to that!

If it turns out that it is the wrong variant for the target, we can still transform into the other direction during code selection. Of course this rule cannot universally be applied if reversing the operation in the backend is unreasonable.

(and of course for this specific case we have to decide first whether the two patterns are equivalent anyway given existing llvm backends)

- Matthias

> On Apr 11, 2016, at 12:55 PM, via llvm-dev <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
> 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/20160411/8d973122/attachment.html>