[llvm-dev] Implementing a proposed InstCombine optimization

Thu Apr 7 16:11:06 PDT 2016

I've submitted a patch and added you both as reviewers: http://reviews.llvm.org/D18874

 - CL

> On Apr 7, 2016, at 5:27 PM, escha at apple.com wrote:
> 
> I feel like a reasonable way of defining it would be that it’s IEEE-754-like, except that if the target diverges from IEEE-754 (in terms of ’missing some part of IEEE-754’ or ‘less precise than IEEE-574’ etc), the transformations we introduce shouldn’t break *other things*.
> 
> e.g. if a target does not support denormals, float ops throughout LLVM are as such free to lose their denormals at any time. This doesn’t normally cause problems, but if you allow turning int ops into float ops, you now allow int operations to destroy denormals at any time, which is more powerful (and more dangerous) than the target natively defines, I think.
> 
> —escha
> 
> 
>> On Apr 7, 2016, at 1:46 PM, Sanjay Patel <spatel at rotateright.com <mailto:spatel at rotateright.com>> wrote:
>> 
>> 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 <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 <mailto: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 <mailto: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 <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>
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/c420c6f4/attachment.html>