Re: question on register spill behavior

BX <bxin@acm.org> writes:
> I am not so on top of the inner workings of the register spill
>behavior. Can the spill code be placed in an inner scope of where the
>register is defined? An example,
>
><code>
>x = .. //suppose it's allocated a register
>if(..) {
> //can spill code for 'x' placed here??
> ...
> .. = x;
> foo();
>}
>.. = x;
></code>


That is called live range splitting.


Without live range splitting colouring register allocators spill a
live range completely (loading it right before every use and storing
it right after every def, possibly with some optimizations limited to
basic blocks).


> It seems nothing forbids it. My question is, with the existing spill
>algorithm in popular compilers (e.g. GCC), can the above scenario
>happen?


Classically, GCC used a simple colouring register allocator without
live range splitting. They have done a lot in the last years, but
AFAIK all attempts to improve the register allocator have failed.


I don't know if other compilers use live-range splitting, but I guess
that some do.


> In most cases, register spill code seems to be at the beginning of a
>function (pushs) and end of a function (pops).


Yes, that's my impression of gcc, too: It spills the callee-saved
registers on entry and refills them on exit, and never saves and
restores caller-saved registers around calls (but instead uses them
only for live ranges that don't survive calls), and then allocates
live ranges into the now-free register ranges.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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