|
From: Julian S. <js...@ac...> - 2008-03-25 11:44:21
|
> Currently it only removes redudant MOVs between virtual registers that can > be propagated forward. Imagine this: > > 9 movl %vr16,%vr85 ; %vr16 isn't referenced below this line > 10 subl $0x4,%vr85 > > (maps %vr85 to %vr16) > > the movl is removed and translated into: > 9 subl $0x4,%vr16 Yes. However the register allocator does the same transformation (virtual-to-virtual register move coalescing), in the case where the source register's live range ends at the move instruction and the destination register's live range starts at the move instruction. That allows the instruction selectors to generate apparently-stupid code with lots of v-v moves, and reg-alloc then cleans it up later. This makes construction of the instruction selectors much simpler, especially for 2-address targets (x86, amd64). Or are you doing something else apart from V-V coalescing? > (memcheck creates some unnecessary moves because > of the dirty handler arguments). Yes .. it could probably do better in cases where a V(irtual) register is moved to a (R)eal register, and the V's live range ends at that point. I think I tried to add a "preference" mechanism to regalloc2.c, which says, for each virtual reg, which real reg it would "prefer" to be in, for this reason. But I also think that didn't help, because it constrains regalloc's choice of registers and so just moves the reg-to-reg moves elsewhere. However, I didn't investigate much; you may be able to do better. > Do you know what might be causing the problem? Check carefully the validity of the transformation(s) you do. It's easy to break stuff at this level. J |