Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> The register coloring algorithm's not dirtying registers right,
> There are still some compatibility hooks inside parrot that set P1 on
> the caller's end (or on both sides). I'll remove this remenants RSN.
Looking a bit deeper into this bug reveals that above sentence doesn't
describe fully what happens, and it additionally depends on the register
allocator (CVS or new).
1) current CVS allocator
* P28 .. P30 are used to allocate temps and not allocated else
* P31 is reserved for spilling
* the old allocator doesn't have the code WRT preserved registers, which
was written for the new one (it could be backported)
* the register allocator needs 3 more registers and allocates P0, P1, P3
(P2 is visible in "set P2, Px" that moves the object in place)
Now implicit register usage strikes back. The register allocator isn't
aware of the side effect that C<callmethodcc> clobbers P0, P1, and S0.
2) new allocator
* has a list of allocatables usable for temps and has a clear notion
of preserved vs non-preserved registers
static const char assignable[4][5] = {
/* 0 1 2 3 4 */
{ 0, 0, 0, 0, 0, }, /* I */
{ 0, 1, 1, 1, 1, }, /* S */
{ 0, 0, 0, 1, 1, }, /* P */
{ 1, 1, 1, 1, 1, }, /* N */
};
* code would execute correctly, one more used register would cause
spilling
leo
