Re: Additional peephole pass(es)

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

Hi!

On Mon, Apr 20, 2020 at 12:20:35PM +0200, Stefan Franke wrote:
> is there a chance that a patch would be accepted if it adds (an) additional
> peephole pass(es)?

That would need some serious justification.

> I'm not content with the capabilities of the combine pass

Sorry to hear that.  Do you have any concrete complaints?

> 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

Spaghetti code?  Heh.  There is a lot of run-on code; there is a little
bit of action-at-a-distance; and almost all other sins imaginable are
committed somewhere as well, but spaghetti?  Not so much :-)

> 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?

It probably would help if you could start with an example that shows
that an extra peephole pass would help.


Segher