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

[David Majnemer]

On Sat, Oct 18, 2014 at 5:36 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> 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.
>

This transform is matching "(sub (or A B) (xor A B)) -> (and A B)" which is
similar to "(add (and A, B) (xor A, B)) -> (or A, B)" but I'm having
trouble seeing how the (add (and ... )) could turn into a (sub (or ...)).
If it's possible, then we need this transform without a doubt.


>
> 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.
>

+10
The fact that these transforms need to be expressed this way is not awesome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141018/6d1aff1e/attachment.html>