[llvm-dev] Implementing a proposed InstCombine optimization

[Sanjay Patel via llvm-dev]

Yes, if transforming the int op to an FP op induces target-dependent
behavior, then we can't do this transform in InstCombine without some kind
of predication. And we should revert or rein in:
http://reviews.llvm.org/rL249702

As I noted in that commit message, it's not clear what the FP model of LLVM
IR actually is. Based on existing IR transforms, I assumed it was
IEEE-754...ish.


On Thu, Apr 7, 2016 at 10:43 AM, <escha at apple.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) and either canonicalize
> NaNs or don’t support denormals. This is actually important because this
> kind of bitmath on floats is very commonly used as part of algorithms for
> complex math functions that need to get precise bit patterns from the
> source (similarly for the transformation of masking off the sign bit ->
> fabs). It’s also important because if the float happens to “really” be an
> integer, it’s highly likely we’ll end up zero-flushing it and losing the
> data.
>
> Example:
>
> a = load float
> b = bitcast a to int
> c = xor b, signbit
> d = bitcast c to float
> store d
>
> Personally I would feel this is safe if and only if the float is coming
> from an arithmetic operation — in that case, we know that doing another
> arithmetic operation on it should be safe, since it’s already canonalized
> and can’t be a denorm [if the platform doesn’t support them].
>
> I say this coming only a few weeks after our team spent literally dozens
> of human-hours tracking down an extremely obscure bug involving a GL
> conformance test in which ints were casted to floats, manipulated with
> float instructions, then sent back to int, resulting in the ints being
> flushed to zero and the test failing.
>
> —escha
>
>
> On Apr 7, 2016, at 9:09 AM, Sanjay Patel via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi Carlos -
>
> That sounds like a good patch.
>
> Warning - following the link below may remove some of the educational joy
> for the immediate task at hand:
> http://reviews.llvm.org/D13076
>
> ...but I wouldn't worry too much, there's plenty more opportunity where
> that came from. :)
>
> Feel free to post follow-up questions here or via a patch review on
> Phabricator:
> http://llvm.org/docs/Phabricator.html
>
>
> On Thu, Apr 7, 2016 at 7:17 AM, Carlos Liam via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I'm interested in implementing an InstCombine optimization that I
>> discovered and verified with Alive-NJ (with the help of the authors of
>> Alive-NJ). The optimization is described in Alive-NJ format as follows:
>>
>> Name: xor->fsub
>> Pre: isSignBit(C)
>> %x = bitcast %A
>> %y = xor %x, C
>> %z = bitcast %y
>> =>
>> %z = fsub -0.0, %A
>>
>> Effectively the optimization targets code that casts a float to an int
>> with the same width, XORs the sign bit, and casts back to float, and
>> replaces it with a subtraction from -0.0.
>>
>> I am not very familiar with C++ or the LLVM codebase so I would greatly
>> appreciate some help in writing a patch adding this optimization.
>>
>> Thanks in advance.
>>
>>  - CL
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> 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/20160407/911b68af/attachment.html>