Re: Graph colouring and local register allocation
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Sun, 09 Dec 2007 15:40:07 -0800
Torben Fgidius Mogensen wrote:
(snip)
Actually, register reuse is not a problem on most OOO architectures,
as they use register renaming at runtime to avoid this kind of
dependencies. And on processors that do dynamic runtime scheduling,
compile-time scheduling is less important than avoiding spills: The
processor can to some extent schedule around a bad compile-time
schedule, but it can't undo a spill.
The 360/91 floating point unit, designed for an architecture with only
four floating point registers, had to be able to undo a spill. Memory
load requests look in the store buffer for a recent store, and will
take the value directly from the store buffer. A later store to the
same address will cancel the previous store request. (Assuming all
hazards are resolved.) If the source of the store hasn't completed
yet, register renaming will get back to the original source. A spill
inside a tight loop will likely be resolved by the processor logic,
with only the final value actually stored.
-- glen
.
- References:
- Re: Graph colouring and local register allocation
- From: Sid Touati
- Re: Graph colouring and local register allocation
- From: George Neuner
- Re: Graph colouring and local register allocation
- From: preston.briggs@xxxxxxxxx
- Re: Graph colouring and local register allocation
- From: George Neuner
- Re: Graph colouring and local register allocation
- From: Pertti Kellomäki
- Re: Graph colouring and local register allocation
- Prev by Date: Re: ANSI C grammar without shift-reduce conflict on 'ELSE'
- Next by Date: Re: Implementing Thompson's construction
- Previous by thread: Re: Graph colouring and local register allocation
- Next by thread: Re: Graph colouring and local register allocation
- Index(es):
Relevant Pages
|
|