On Thu, Apr 23, 2020 at 09:32:37AM +0200, Richard Biener wrote:
> On Thu, Apr 23, 2020 at 12:31 AM Jeff Law <l...@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.
RTL is a *feature*, and it is one of the things that makes GCC
significantly better than the competition.
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.
Segher
