[PATCH] simplify-rtx: Transform (xor (and (xor A B) C) B) with C const

Segher Boessenkool segher@kernel.crashing.org
Wed Nov 9 23:05:00 GMT 2016


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?

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

I don't know either.  See PR63568.

> (simplify
>  (bit_xor:cs (bit_and:s (bit_xor:cs @0 @1) CONSTANT_CLASS_P@2) @0)
>  (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)

No clue.  There is a theme here ;-)


Segher



More information about the Gcc-patches mailing list