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