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