[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