[PATCH] InstCombine ((x | ~y) ^ (~x ^ y)) to (x & ~y)

MAYUR PANDEY mayur.p at samsung.com
Thu Aug 28 05:59:45 PDT 2014


Hi Daniel, Anton,

There is a discussion is going on at http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075532.html regarding a more general way to handle matching 
different patterns. If we can come up with a general approach that would be best. But till then we should not miss any optimizing opportunity I think.

Thanks,
Mayur

------- Original Message -------
Sender : Daniel Berlin<dberlin at dberlin.org>
Date : Aug 23, 2014 06:06 (GMT+09:00)
Title : Re: [PATCH] InstCombine ((x | ~y) ^ (~x ^ y)) to (x & ~y)






On Fri, Aug 22, 2014 at 12:11 PM, Richard Smith <richard at metafoo.co.uk> wrote: 

On Fri, Aug 22, 2014 at 11:14 AM, David Majnemer <david.majnemer at gmail.com> wrote: 

This can be generalized: 

`(X | (Y ^ Z)) ^ ((X ^ Z) ^ Y)` -> `X & (Y ^ Z)` 


Is matching that really the right approach? I would (perhaps naively) think we should instead CSE that to


  (X | A) ^ X ^ A   (with A = Y ^ Z) 



... and we should be able to perform these more primitive transformations:


 (X | A) ^ X -> ~X & A
 (~X & A) ^ A -> X & A


... which together reduce your expression to X & (Y ^ Z). Perhaps one of those takes us further from canonical form, though. What are the rules for canonicity here?




Bringing this up, so far the answers to "why do we keep adding transforms here" has been "to improve matching capabilities" (which is a result, not an objective).  I'd really love it if someone could step back and present a real design (Defining what canonical forms should instcombine expect as input or output) rather than add a ton of possibly used/not used transforms that may or may not transform things back and forth.



  
_______________________________________________ 
llvm-commits mailing list 
llvm-commits at cs.uiuc.edu 
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits 




More information about the llvm-commits mailing list