|
From: Nuno L. <nun...@sa...> - 2008-03-26 15:38:39
|
>>>> 20 movl 0x2A8(%ebp),%edx ; load %vr30 from memory >>>> 21 andl $0xFFFF,%edx >>>> 22 movl 0x2A8(%ebp),%edx ; <-- %vr30 is in %edx, not in memory >>>> 23 movl %edi,%eax >>>> 24 call[2] 0x38006C30 >>>> >>>> So the problem is that the register allocator gets confused somehow and >>>> loads %vr30 twice, destroying its value (i.e. the line 22 is bogus and >>>> could be removed altogether). >>> >>> That's very strange. After the reload on line 20, it should indeed >>> have noted that %vr30 is now in %edx, so then there would be no need >>> to incorrectly reload it again at line 22. I have no idea why. >> >> So well, any idea on how to debug that problem? I have zero knowledge >> about >> register allocation algorithms, hence my relutance to get my hands on >> it.. > > So this patch almost fixes the problem: > http://web.ist.utl.pt/nuno.lopes/vex_regalloc_mov_vr.txt > It removes mov instructions between a virtual register and a real > register, > as long as the virtual register is mapped to the real register. But then > it > fails the sanity check at line 939 (rreg_state[k].disp == Unavail) for the > rreg of the previous mov instruction we had just skip. > So, the idea seems ok, but the patch needs some work to fix that > assertion. > Julian, could you take a look at it, please? never mind. I've already discovered the problem and updated the patch accordingly (link above). Can you please check if the patch is ok (and commit it if it's ok)? Thanks, Nuno |