This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: An unusual Performance approach using Synthetic registers


On Sunday 29 December 2002 01:47 pm, Daniel Berlin wrote:

<snip>

> > My approach may allow for an effectively infinite register set.
>
> Which we have (Chris is wrong, we don't perform optimizations on
> physical registers, we perform it on an infinite register set), and the
> register allocator simply thunks the infinite number down to the real
> number we have on the architecture.

umm.  This is sort of the point of my whole approach.  I didn't call them 
"virtual", because they are not a simulation of a register, using a lot of 
instructions to perform a simple operation.  I didn't call them "pseudo" 
because they are not slow memory imitations of a register.  Because of the 
x86 architecture, they may be used with many instructions similar to "real" 
registers.  Because of the narrow way they are defined, they will perform 
with speed similar to "real" registers.  

I am adding to the "real" number we have on the architecure.  These are 
Synthetic: artificial duplicates of the originals, with many of the same 
characteristics.  I am specifically not including basing or indexing.

> >   For each
> > subroutine, the compiler figures out how many registers are needed.
> > Right
> > now, in GCC, the next step after adding up the number of registers is
> > to call
> > Daniel Berlin's implementation of Color-Graphing.
>
> First, this is incorrect.
> Right now use an ad-hoc register allocator that isn't all that good
> unless you specifically use -fnew-ra.

Ok.

> Second, Michael Matz is responsible for more of the new allocator than
> me (i'm just trying to give credit where it's due).

Second: I stand corrected.  Michael Matz' and Daniel Berlin's Color-Graphing 
implementation.  

Credit where it is due, indeed!  Many thanks to Michael Matz and Daniel 
Berlin.

Andy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]