This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: An unusual Performance approach using Synthetic registers
On Sunday 29 December 2002 06:26 pm, Zack Weinberg wrote:
> Andy Walker <ja_walker@earthlink.net> writes:
> > On Sunday 29 December 2002 02:04 pm, Diego Novillo wrote:
> >> On Sun, 29 Dec 2002, Andy Walker wrote:
> >> > My approach may allow for an effectively infinite register set. For
> >> > each
> >>
> >> Eh? GCC already uses that approach. RTL is a register language
> >> for an abstract machine with an infinite number of register.
> >>
> >>
> >> Diego.
> >
> > I agree. RTL is for an abstract machine. Infinite register set.
> > Excellent approach.
> >
> > Synthetic registers are artificial registers for a real machine.
>
> [...]
>
> What I think Diego is trying to say is, creating synthetic registers
> for the x86 isn't going to help much, possibly not at all, because the
> optimizer passes that could benefit already have unlimited registers
> to work with. I agree with this assessment. The problems which cause
> GCC to generate inferior code on register-starved architectures are
> intrinsic to the register allocator: lack of live-range splitting, the
> ad-hoc two-phase allocation algorithm (which makes awful choices), and
> the reload nightmare. I suspect you will get more for your time by
> working with Michael and Daniel to complete the new register
> allocator, targetted to the real architectural register set.
>
> There's another angle of potential improvement, which is, GCC is
> totally incapable of optimizing stack frame layout. Stack slots are
> assigned in linear order and never recycled; the stack pointer is kept
> aligned whether or not this is necessary; and so on. In this domain I
> think the sane thing to do is, whenever we have to put something on
> the stack, create a new pseudo register pointing directly to it.
>
Perhaps...
In addition to the current distinction of an unlimited number of pseudo
registers, and;
The actual, physical registers PLUS stack slots that pseudo registers
could be (and eventually are) assigned/resolved too...
Define a new distinction composed of a large, but limited number of
registers, on which;
The current pseudo register optimizations can be run against, and;
They are usable (if they still exist at the register/stack slot assignment
stage) by the machines existing instruction (sub)set.
Of course, to talk about this specialized class of pseudo registers
(or specialized class of pyhsical machine registers - your choice);
one should attach an unused name to them.
An array of Synthetic Register Frames sounds like a workable name.
Hmmm... I think Andy just did that.
If, once Andy reachs the point that he feels his code is working as
he intended...
Someone wanted to throw away the current stack slot assignment/
register reload mess, and instead;
Within the code that assigns his Synthetic Registers, instead;
assign some or all of them to the hardware's stack frame (stack
slots)...
I think you would both reach the same goals. Incrementally
of course.
In fewer words;
I think Andy's approach has merit and could well
lead to general improvements in the compiler.
Even if his Synthetic Register Frames eventual disappear completely,
along with the stack slot/register reload mess.
Now if some brave soul would step forward to either extend RTL or
define an RTL like symbolic representation of structured data (a
symbolic, position independant data description) to replace the
"assign it as we find" system now used...
Somebody take my keyboard away, I am beginning to ramble on...
Mike
Mike