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
Tinterferencebitmap.setbitmap.
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
coalesced.
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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
