https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 10 Feb 2021, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986 > > rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rsandifo at gcc dot gnu.org > > --- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> > --- > Yeah, I think making the canonicalisation rules go deep into > the operands has scalability problems. > > FWIW, another similar thing I've wanted in the past is to try > recognising multiple possible constants in an (and X (const_int N)) > when X is known to have some bits clear. Often we try to make N contain > as few bits as possible, but that can give worse results than a fuller mask. > > I had a WIP patch for this and binary order thing. It used a wrapper > around recog (in recog.c) to apply useful-looking variations. > Of course, trying multiple variations has scalability issues too, > so it would need some kind of limiter. So this is where the "autogenerated" part comes in. We should have an idea what might be useful and what isn't even worth trying by looking at the machine description (which might require exposing costs in such form for this case of constants). For commutative operands maybe recog itself can be relaxed and accept the insn with the "wrong" commutation (or fix it up itself) for example. Or maybe genrecog can magically emit commutated variants (like genmatch does for :c annotated expression branches).
