Re: Additional peephole pass(es)

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

On Sat, Apr 25, 2020 at 01:04:45PM +0900, Oleg Endo wrote:
> On Fri, 2020-04-24 at 16:36 -0500, Segher Boessenkool wrote:
> > 
> > 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?)
> 
> No, that's not what I meant.  What I meant was really custom "combine-
> like" steps which combine would never do by itself.  split1 gives you a
> simple "interface" to hook into each insn without writing a full custom
> pass.

Ah right, the T reg passes.

For GCC 11 I want to do 1-to-1 combinations as well, which helps for a
bunch of things, including it can perhaps make your sett/clrt pass
superfluous.  We'll see :-)

The treg_combine pass...  I don't see why when the problem is inside a
single basic block, why then combine cannot handle it?

But of course most of the time it is over BB edges.  Maybe fwprop or
Richard's proposed new "combine2" can handle this generically?

> For example, on SH I've used that to implement additional elimination
> of sign/zero extending memory loads.  On RX I did the same to fold some
> in-memory operations, which neither combine nor peephole passes would
> catch otherwise.

Yeah, we need some more infrastructure to start to tackle that
generically (and I'm not at all sure that that will help enough).


Segher