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? Segher
