Re: Additional peephole pass(es)

[Oleg Endo <oleg.endo@t-online.de>]

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