|question on register spill behavior firstname.lastname@example.org (BX) (2008-08-27)|
|Re: question on register spill behavior email@example.com (2008-08-28)|
|Re: question on register spill behavior firstname.lastname@example.org (cr88192) (2008-08-29)|
|Re: question on register spill behavior email@example.com (BX) (2008-09-08)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||Thu, 28 Aug 2008 14:47:22 GMT|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Posted-Date:||28 Aug 2008 17:34:46 EDT|
BX <email@example.com> 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,
>x = .. //suppose it's allocated a register
> //can spill code for 'x' placed here??
> .. = x;
>.. = x;
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
> It seems nothing forbids it. My question is, with the existing spill
>algorithm in popular compilers (e.g. GCC), can the above scenario
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.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.