Home > Archive > Compilers > November 2007 > Register Spilling Heuristic ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Register Spilling Heuristic ?
|
|
| Mohamed Shafi 2007-10-24, 7:27 pm |
| Hello all,
I am trying to implement Briggs register allocator. While doing that i
came across documents indicating how to choose nodes for spilling. The
documents says to avoid choosing nodes that are the tiny live ranges
resulting from the fetches of previously spilled registers.
What does this mean? Does it mean that the definition points of a
spilled live range that have been stored to memory in a previous
spilling iteration do not need to be stored again and the definition
points of a spilled live range that begin with spill loads that were
inserted in a previous spilling iteration do not need to be stored.
Any help is appreciated.
Regards,
Shafi.
| |
| preston.briggs@gmail.com 2007-10-24, 7:27 pm |
| On Oct 23, 9:49 pm, "Mohamed Shafi" <shafi...@gmail.com> wrote:
> I am trying to implement Briggs register allocator. While doing that i
> came across documents indicating how to choose nodes for spilling. The
> documents says to avoid choosing nodes that are the tiny live ranges
> resulting from the fetches of previously spilled registers.
>
> What does this mean? [...]
Generally, when a live range is spilled, a store is inserted
immediately after each definition of the live range and a load is
inserted immediately before each use. These new instructions define
new live ranges (for example, reaching from an existing definition to
a new store) that should not be spilled again (because they are so
show that there's possible profit in spilling them). In my allocator,
such live ranges are given an infinite spill cost and will not be
spilled.
My impression is that some people, in attempting to implement my
allocator, get the calculation of spill costs wrong, especially for
these very short ranges. This causes their allocators to run for a
long time, repeatedly spilling and rebuilding the interference
graph...
Care is required. Implement plenty of debugging infrastructure to
help you examine computed spill costs and make sure they're correct.
Preston
| |
|
|
|
|
|