Hi, On Mon, 2020-04-20 at 12:20 +0200, Stefan Franke wrote: > > is there a chance that a patch would be accepted if it adds (an) additional > peephole pass(es)? > > > I'm not content with the capabilities of the combine pass and a convenient > way would be to insert an additional pass in front/after the combine pass. > It's way easier to maintain than the spaghetti code in combine and ss long > there is nothing defined in the cpu's md file, the pass gets skipped, so the > overhead for non-users is almost non existent. > > > Right now I'm applying the same set as in the final peephole run, but I > would add a separate keyword per pass, e.g. peephole_precombine, etc. p.p. > > > Your thoughts? > Yeah, it's true, combine doesn't catch every possible combination and the canonical form is also sometimes questionable. You can add additional passes in the backend as you like. If a particular additional pass for a particular backend results in significant improvements in code quality or such, then why not? You can also do "manual combine" of certain insns in the split1 pass that runs after combine. For some examples you can browse through the SH backend. The problem with peepholes is that they tend to break easily because they depend on insn order. If something else in the compiler decides to insert insns between two related insns, peephole patterns usually break. Cheers, Oleg
