On 11/10/2016 03:43 AM, Richard Biener wrote:
On Thu, Nov 10, 2016 at 12:05 AM, Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
On Wed, Nov 09, 2016 at 11:29:45PM +0100, Marc Glisse wrote:
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)
And a shallower evaluation tree.
Does match.pd (or the gimple optimisers in general) care about the number
of constants at all?
It's a matter of definition what is simpler. I think for two
different constants vs
one constant I'd prefer the single constant (the match.pd pattern would apply
to int128 as well). Unless you have a andnot instruction and combine/CSE
are clever enough to see the opportunity to re-use a previous constant if
it changes bit-and to bit-and-not ...
I'd at _most_ consider them equal cost which would mean we'd need to
decide for a canonical form -- having the same one for constant and not constant
seems like a good idea here as well.
bernd notices better resource utilization due to the shallower tree for the
ior variant but that also eventually increases register pressure.
Thus, I'd leave this all to RTL land ;) (esp. the constant with
and-not instruction
trick is likely not done on RTL)
Definitely seems like we want to keep the match.pd transformation, then
potentially un-do it in the RTL world where we can query target costs,
supported insns, etc.
jeff
