Hi! On Tue, Apr 21, 2020 at 02:34:09AM +0900, Oleg Endo wrote: > Yeah, it's true, combine doesn't catch every possible combination and > the canonical form is also sometimes questionable. Yeah. Bug reports welcome! This isn't "canonical" usually; but all targets depend more or less on what insns combine used to generate. Even for comparably tiny changes (that are a net good thing for all targets!) people become very unhappy already, so yeah it is some kinf of "de facto" canonical: but it is not that we promised this is the form we would use, and it is not that we think this is the best and we should not change it; the problem just is inertia. > 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. In combine itself runs split as well (one insn to two). And you can add instruction patterns to your machine description that are only there for combine: you split them to separate insns immediately again (maybe this is what you meant though?) > 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. Another big problem is that it is very, very hard to write a *correct* (non-trivial) peephole2. Segher
