Re: managing register spills?

David L Moore <dlmoore@ix.netcom.com>
13 Jun 1997 22:05:11 -0400

          From comp.compilers

Related articles
managing register spills? gclind01@starbase.spd.louisville.edu (1997-06-10)
Re: managing register spills? cliffc@risc.sps.mot.com (Cliff Click) (1997-06-13)
Re: managing register spills? preston@cs.rice.edu (1997-06-13)
Re: managing register spills? dlmoore@ix.netcom.com (David L Moore) (1997-06-13)
| List of all articles for this month |

From: David L Moore <dlmoore@ix.netcom.com>
Newsgroups: comp.compilers
Date: 13 Jun 1997 22:05:11 -0400
Organization: Netcom
References: 97-06-030
Keywords: registers, optimize, code

George C. Lindauer wrote:
> [How to use push and pop to spill and fill]


In general, you cannot expect all spills and fills to be pushes and
pops since in general you are evaluationg a dag rather than a tree.
Hence, registers will not spill in the reverse order to the fill and
you may want to fill a register more than once - once you have spilled
a cse you can avoid re-spilling it. If you pop such a value, you
cannot avoid an extra spill.


Hence, you will need to be able to spill to allocated memory addresses
in your stack frame. You can then use pushes and pops on an
opportunistic basis.


Only a few machines have push and pop anymore. I am not even sure if a
push/pop is faster than the longer store/load instructions on a
pentium pro. This machine has a look-aside table for loads and stores
which reduce delays waiting for the primary cache to be updated. If
the address is not available until late, it could conceivably
introduce a bubble while this table is consulted.


(If memory serves correctly, the Alpha also has such a
buffer. Possibly, the Alpha was the first processor to have such a
buffer, but I am a bit vague on when the Pentium Pro first shipped;
the Alpha chip which I believe had this shipped in late 1994 or early
to mid 95)


David Moore
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.