Re: Additional peephole pass(es)

[Segher Boessenkool <segher@kernel.crashing.org>]

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