[PATCH] Fix MachineCopyPropagation with subregs

[Jakob Stoklund Olesen]

On Jan 21, 2014, at 11:24 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>> MachineCopyPropagation has special logic for removing COPY
>> instructions. It will remove plain COPYs using eraseFromParent(),
>> but if the COPY has imp-defs/imp-uses it will convert it to a KILL,
>> to keep the imp-def around.
>> 
>> This actually totally breaks and causes the machine verifier to cry
>> in several cases, one of which being:
>> 
>> %RAX<def> = COPY %RCX<kill>
>> %ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill>
>> 
>> These subregister copies are together identified as noops, so are
>> both removed. However, the second one as it has an imp-use gets
>> converted into a kill:
>> 
>> %ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>
>> 
>> As the original COPY has been removed, the verifier goes into tears
>> at the use of undefined EAX and RAX.
>> 
>> 
>> These implicit register operands after register allocation are quite
>> annoying and really hard to get right in a pass like this. They do
>> provide a more precise liveness tracking, but I don’t think that a
>> lot of targets actually benefit from the extra precision.
> 
> Am I correct in thinking that the benefit comes on targets that have independently-usable subregisters (so that, for example, the scavenger might separately allocate both al and ah on x86)? Maybe ARM would notice if we always "upcasted" liveness to the largest super-register (since they have those register pairs, etc.).

Yes, we would need to make sure that the scavenger works for ARM GPRs, even when they have GPRPair super-registers.

It would also constrain the late scheduler. Consider:

eax = def1
use1 eax
ax = def2
use2 eax

It’s not clear if use2 depends on the ‘old’ bits in the high half of eax, or if it would be safe to reorder like this:

ax = def2
use2 eax
eax = def1
use1 eax

With an eax<imp-def> operand on def2, the dependency on def1 is broken, so it is safe to reorder. I don’t think the scheduler will actually do something like that today, though.

Thanks,
/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140121/369ec6fd/attachment.html>