[RFC] split pseudos during loop unrolling in RTL unroller

[Richard Biener]

On Thu, Apr 23, 2020 at 12:17 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote:
> > On Thu, Apr 23, 2020 at 12:31 AM Jeff Law <law@redhat.com> wrote:
> > > On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote:
> > > > > > In some ways it feels like it would be easier to resurrect RTL SSA :-)
> > > >
> > > > Why was RTL SSA abandoned?
> > > >
> > > > It might well work to keep everything in SSA form all the way to RA.
> > > > Hrm, that doesn't sound bad at all :-)
> > > >
> > > > (The PHIs need to be made explicit to something that resembles the
> > > > machine code we will end up with, very early in the pipeline, but it
> > > > could still also be some valid SSA form; and we can of course also
> > > > have hard registers in all RTL, so that needs to be dealt with sanely
> > > > some way as well  Lots of details, I don't see a crucial problem though,
> > > > probably means I need to look harder ;-) )
> > > Lack of time mostly.  There's some complications like subregs, argument registers
> > > and the like.  But you can restrict ssa based analysis & optimizations to just
> > > the set of pseudos that are in SSA form and do something more conservative on the
> > > rest.
> >
> > I guess time is better spent on trying to extend GIMPLE + SSA up to RA, thus
> > make instruction selection on GIMPLE.
>
> I think this is a bad idea.  By the time you have invented enough new
> "lower GIMPLE" ("limple"?) to be able to use it to describe machine
> insns like we can with RTL, you will have a more verbose, more memory
> hungry, slower, etc. reinvented RTL.

I don't think there's much to invent.

I think at least one step would be uncontroversical(?), namely moving
the RTL expansion "magic"
up to a GIMPLE pass.  Where the "magic" would be to turn
GIMPLE stmts not directly expandable via an existing optab into
GIMPLE that can be trivially expanded.  That includes eventually
combining multiple stmts into more powerful instructions and
doing the magic we have in, like, expand_binop (widening, etc.).
Where there's not a 1:1 mapping of a GIMPLE stmt to an optab
GIMPLE gets direct-internal-fn calls.
Then RTL expansion would be mostly invoking gen_insn (optab-code).

More controversical would be ending up in GIMPLE there.  I think
GIMPLE can handle all RTL insns if we massage GIMPLE_ASM
a bit.  You'd end up with, say,

 asm ("(set (reg:DI $0)
                (and:DI (reg/v:DI $1 [ dst ])
                    (reg:DI $2)))" : "r" (_1) : "r" (_2), "r" (_3) : "cc");

in place of

  _1 = _2 & _3;

and the GIMPLE_ASM text could be actual RTL.  We'd extend
the stmt with an extra operand to denote recognized patterns,
so another option would be to keep the original GIMPLE as well.

> RTL is a *feature*, and it is one of the things that makes GCC
> significantly better than the competition.

That said, I actually agree with that.  It's just that I hope we can
make some of the knowledge just represented on the RTL side
available on the GIMPLE side.  The more complicated parts,
like calling conventions, that is.

And yes, I want to get rid of that expand monster to be able to
do something like sched1 on "GIMPLE" without expand coming
along and re-scheduling everything at-will.

> More optimisations should move to GIMPLE, for example some loop
> optimisations should be done much earlier (most unrolling).  The expand
> pass should lose most of the "optimisations" it has built up over the
> decades (that now often are detrimental at best).  Some of what expand
> now does should probably be done while still in GIMPLE, even.
>
> But it is very useful to have a separate "low level" representation,
> that is actually close to the machine code we will eventually generate.
> RTL is one such representation, and we already have it, and it is very
> well tuned by now -- throwing it away would require some *huge*
> advantage, because the costs of doing that are immense as well.

But being stuck with something means no progress...  I know
very well it's 100 times harder to get rid of something than to
add something new ontop.

Richard.

>
> Segher