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
- From: Michael S. Zick <mszick at goquest dot com>
- To: dewar at gnat dot com (Robert Dewar),ja_walker at earthlink dot net
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 5 Jan 2003 09:42:47 -0600
- Subject: Re: An unusual Performance approach using Synthetic registers
- References: <20030105113840.BF53CF28C4@nile.gnat.com>
On Sunday 05 January 2003 05:38 am, Robert Dewar wrote:
> > Before I started this, I had never heard of an optimization technique
> > that tries to take advantage of L1 cache. That may very well indicate
> > that the register allocator really is "just dumb". (No flame wars,
> > please. Outstanding and brilliant developers did the best they could with
> > the algorithms they had. I sincerely doubt that I could have done as
> > well).
>
> This is a bit of an odd statement. In practice on a machine like the x86,
> the current stack frame will typically be resident in L1 cache, and that's
> where the register allocator spills to. What some of us still don't see
> is the difference in final resulting code between your "synthetic
> registers" and normal spill locations from the register allocator.
>
> Perhaps you could give at least a small example of actual code. We all know
> that (even on the 486), register register moves take the same time as
> register-local stack frame moves when the local stack frame is in cache,
- - ^ ^ ^ ^ ^ ^
> and the code that GCC generates now heavily depends on this.
Sort of.
The ia32 instruction set is not limited to load/store and push/pop of a data
item in the stack frame.
The ia32 does not provide a separate cache for stack instructions (S-cache).
Also, typical program memory layout places the stack/heap and data/bss in the
same address space.
-> on the ia32, stack frame operations and data area operations both hit
the D-cache.
Which brings us back to the original question:
"What is the difference between an allocated spill slot in the stack frame
and a synthetic register in the stack frame?"
Ans. 1) From the operation of the hardware - nothing, zip, zero, nada.
Ans. 2) From the domain of instructions GCC might generate, perhaps
a whole lot, but, then again perhaps not.
So, to quantify Ans. 2, as a matter of pratical implimentation; rather than
do a re-write of the spill slot allocation and code generation selection for
spill slots; just define a new set of registers with a limited subset of
instructions - run the compiler, examine the result.
Question: "Does GCC use spill slots as effectively as the synthetic
registers?"
If not - fix something, with the differences in usage as a guide.
Mike