Re: An unusual Performance approach using Synthetic registers

[Andy Walker <ja_walker at earthlink dot net>]

Thank you for the explanation.  

On Sunday 29 December 2002 06:26 pm, Zack Weinberg wrote:
<snip>
> 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.  

I completely agree that Synthetic registers will have no impact on optimizer 
passes.  If I am reading the GCC code correctly, the optimizer passes (except 
for peephole, also no impact) are all completed a long time before before any 
of my changes have any significant effect.

>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.  

My hope is that these issues will be significantly diminished if the 
architecture is no longer register-starved, and that Color-Graphing will be 
able to do a much better job with more registers.  

Color-Graphing is still critical and necessary.  

>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.

Probably.  Unfortunately, implementing the Synthetic register approach has 
seized me for the moment. 

> 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

I have thought about this issue as well.  

I have wondered about using an address list for current objects.  
I pay good money for a Program when I attend a sporting event or a show.  
That way, I know who are the participants.  Perhaps a witless compiler would 
benefit from the same thing: a block of addresses on the stack, each for a 
current object.  

It would be useless for an itty-bitty program.  A large program might 
benefit.  

Or it might not.

Where I work, we auto-generate huge programs, with tens of thousands of lines 
of code.  Maybe.  Maybe.

Andy