[perl #29837] Register spilling needs a last-gasp give-up scheme
Dan Sugalski
# Please include the string: [perl #29837]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29837 >
It's possible to get the register allocator in what is essentially an
infinite loop, where it runs forever or until it blows memory and
dies. It needs to have a means to check for too many iterations and
fall back to a slow-but-working version with too much spilling.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> It's possible to get the register allocator in what is essentially an
> infinite loop, where it runs forever or until it blows memory and
> dies. It needs to have a means to check for too many iterations and
> fall back to a slow-but-working version with too much spilling.
Ok. After some (useless) spill iterations, the strategy could be to just
spill everything in one run and be done with it. But this is a bit
suboptimal.
A better strategy would be to discard the life range of lexicals and
globals and emit only a fetch for these variables. But that needs some
HLL (or programmer) support for denoting lexicals and globals, e.g.
.lexical "foo"
.global pmc bar # current syntax but unimplemented
I'm not quite sure, if the current C<.global> syntax is useful (it
allows non-PMC types). Anyway, if imcc knows, that the variable is a
global or lexical, the register allocator can do a better job.
leo
Dan Sugalski
>Dan Sugalski <parrotbug...@parrotcode.org> wrote:
>
>> It's possible to get the register allocator in what is essentially an
>> infinite loop, where it runs forever or until it blows memory and
>> dies. It needs to have a means to check for too many iterations and
>> fall back to a slow-but-working version with too much spilling.
>
>Ok. After some (useless) spill iterations, the strategy could be to just
>spill everything in one run and be done with it. But this is a bit
>suboptimal.
True, but less sub-optimal than running until you hit an
out-of-memory condition or give up with a double spill error. :)
>A better strategy would be to discard the life range of lexicals and
>globals and emit only a fetch for these variables. But that needs some
>HLL (or programmer) support for denoting lexicals and globals, e.g.
>
> .lexical "foo"
> .global pmc bar # current syntax but unimplemented
I can see that helping in some circumstances (though not mine) but
the code that the register allocator's having fits with has no .local
declarations at all. It's all $x register usage from beginning to end.
Leopold Toetsch
> I can see that helping in some circumstances (though not mine) but
> the code that the register allocator's having fits with has no .local
> declarations at all. It's all $x register usage from beginning to end.
Don't you have something like variables, which could be stored as
globals?
If you code looked like ...
$Px = global "foo"
# some temps
$Px += temp
... it would automatically cut down the life range of $Px.
One more remark: do you use the same "$Px" in different places (for
different temps/vars) or do you increase "x" for different temps? The
latter should be much better.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> I can see that helping in some circumstances (though not mine) but
>> the code that the register allocator's having fits with has no .local
>> declarations at all. It's all $x register usage from beginning to end.
>
>Don't you have something like variables, which could be stored as
>globals?
>
>If you code looked like ...
>
> $Px = global "foo"
> # some temps
> $Px += temp
>
>... it would automatically cut down the life range of $Px.
Yes, I know. I've done that. Everything is in globals, everything is
fetched only when actually needed, and only lives for the duration of
the basic block. (The compiler keeps a cache and flushes it every
label)
>One more remark: do you use the same "$Px" in different places (for
>different temps/vars) or do you increase "x" for different temps? The
>latter should be much better.
I do the latter. There's no reuse of the $Px temps for different values.