On Wed, 9 Nov 2016, Marc Glisse wrote:
On Wed, 9 Nov 2016, Segher Boessenkool wrote:
On Wed, Nov 09, 2016 at 10:54:53PM +0100, Marc Glisse wrote:
match.pd transforms (A&C)|(B&~C) to ((A^B)&C)^B, which is fewer
operations if C is not const (and it is not on simple tests at least,
this transform is done very early already).
Various processors have "insert" instructions that can do this, but
combine cannot build those from the xor-and-xor, especially it has no
chance at all to do that if A or B or multiple instructions as well
(on PowerPC, the rl[ws]imi instructions that can do this with a rotate,
or a simple shift with appropriate C; other ISAs have similar insns).
This patch makes RTL simplify transform (xor (and (xor A B) C) B) back
to (ior (and A C) (and B ~C)) for constant C (and similar with A instead
of B for that last term).
Would it make sense to implement this transformation in match.pd, next to
the "opposite" one, or do you need it at the RTL level because C only
becomes a constant at that stage?
It becomes a constant in the later gimple passes, but we need it in the RTL
simplifiers as well, even if you also do it in match.pd?
(assuming it is always an improvement, even though it may use the same number
of operations and one more constant)
Sure, it doesn't hurt to have it in both places. It just seems that since the
problem was caused by match.pd in your original testcase, fixing it at that
level (undoing the harm as soon as possible) would make the RTL version less
useful (though not useless). Anyway, I don't feel competent to decide when
which form is preferable, I was just curious.
(simplify
(bit_xor:cs (bit_and:s (bit_xor:cs @0 @1) CONSTANT_CLASS_P@2) @0)
(bit_xor:c (bit_and:s (bit_xor:cs @0 @1) CONSTANT_CLASS_P@2) @0)
without the initial "s" of course... (nice, genmatch does notice something
is wrong if I leave it in)
(bit_ior (bit_and @0 (bit_not @2)) (bit_and @1 @2)))
(this handles vectors as well, I don't know if that is desired)
--
Marc Glisse
