[fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
plugwash at p10link.net
Mon Mar 19 00:44:35 CET 2012
> Then a register is spilled, i.e. replace by a location in memory. This
> may be possible without new registers:
> mov ireg30d,ireg29d -> mov ireg30d,[ebp-40]
> ... but in some cases a help register is needed:
> mov ireg30d,[ebp+20] -> mov ireg99d,[ebp+20]
> mov [ebp-40],ireg99d
> Should a new register is needed, register allocation is completely
> restarted with the new code.
Thanks for the info.
>> My current suspiscion is that something is missing regarding handling
>> of running out of VFP registers and it hasn't been noticed before
>> because noone has tried to do what i'm doing (implementing a calling
>> convention using VFP registers and then stress testing it) but i've
>> no idea where to look in the sourcecode to confirm/refute that idea.
> It doesn't look like spilling happens in your example: I don't see
> moves from/to the stack frame as temporary location.
My suspiscion was that the compiler was trying to spill but not actually
generating any code to implement the spill.
> Perhaps the first thing to check is to add a breakpoint in
> The "versions" of s20 use superregister 50 and 70, so a setbitmap
> (50,70) or (70,50) should be called at some point to tell the register
> allocator both registers are active at the same time and cannot be
I added a debug writeln to setbitmap and it does seem to be being called
with both 50,70 and 70,50. Full output is at http://pastebin.com/3jd8zNkh
More information about the fpc-devel