llvm dev - Apr 2016 - Implementing a proposed InstCombine optimization

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/9253cddc/attachment.html>

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 <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
<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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/29f721ec/attachment.html>