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
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.
We're not bad at optimizing with operands of the form
(mem:MODE (reg:P pseudo)) particularly when they have nonoverlapping
alias sets. These pseudos are specially marked and do not get
allocated to real registers; instead, after we know everything that's
going onto the stack, we replace them all with
(mem:MODE (plus:P (reg:P base) (const_int offset))). Graph-coloring
allocation should work pretty well to lay out the stack frame.
There's trouble if we need scratch registers to calculate some of
these base+offset values, but I think the infrastructure already
exists to deal with that.
zw