[PATCH] [InstCombineAddSub] Added the transformation - "sub (or A B) (xor A B) -> (and A B)"

Chandler Carruth chandlerc at google.com
Sat Oct 18 17:36:28 PDT 2014


On Sat, Oct 18, 2014 at 5:20 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

> On Sat, Oct 18, 2014 at 10:07 AM, Sean Silva <chisophugis at gmail.com>
> wrote:
>
>>
>>
>> On Sat, Oct 18, 2014 at 2:47 AM, David Majnemer <david.majnemer at gmail.com
>> > wrote:
>>
>>> InstCombine is not supposed to handle every possible just because it is
>>> theoretically possible case.  It's engineered to be a series of engineering
>>> tradeoffs.  I don't know what the history of the similar transform is in
>>> VisitAdd, it's possible that it wasn't added in a principled way.
>>>
>>
>> IIRC I did a cursory look at the blame and it was actually you who showed
>> up for the corresponding transform in VisitAdd. Or maybe you were
>> committing a patch for someone? Probably worth taking a look at the log to
>> see if you remember.
>>
>
> I believe it was reduced from the Linux kernel.  Frankly, I fail to see
> the relevance to whether or not we should accept this patch.
>

I think there is utility to ensuring that addition and subtraction support
the same fundamental simplifications as it makes things more principled.
For example, if some other transformation switched the add to a sub or the
user knew one input was negated and thus used a sub to "fix" that, it would
be good to not lose the simplification.

All of this is only really relevant if this is in fact the complementary
case for sub as was added for add. What I really wish is that we had a more
algebraic way of specifying these things once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141018/570c853c/attachment.html>


More information about the llvm-commits mailing list