|
From: Nuno L. <nun...@sa...> - 2008-03-25 15:55:44
|
>> > Or are you doing something else apart from V-V coalescing? >> >> I'm also killing R-V dead stores. (happens when some instruction updates >> e.g. %eax, then %eax is moved to a virtual reg, but it's never used). > > Do you have an example of that, to look at? sure: -- t11 = Shr32(64HIto32(MullU32(0xCCCCCCCD:I32,Add32(Shl32(LDle:I32(t25),0x2:I8),0x27:I32))),0x4:I8) movl $0xCCCCCCCD,%vr139 movl (%vr26),%vr142 movl %vr142,%vr141 shll $2,%vr141 movl %vr141,%vr140 addl $0x27,%vr140 movl %vr140,%eax umull %vr139 movl %edx,%vr138 movl %eax,%vr137 ; <-- dead assignment to: %vr137 movl %vr138,%vr136 shrl $4,%vr136 movl %vr136,%vr12 %vr137 is never referenced after that assignment, so the peephole optimizer removes that line. >> 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.. Regards, Nuno |