
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jan 21, 2014, at 11:24 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:</div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">MachineCopyPropagation has special logic for removing COPY<br>instructions. It will remove plain COPYs using eraseFromParent(),<br>but if the COPY has imp-defs/imp-uses it will convert it to a KILL,<br>to keep the imp-def around.<br><br>This actually totally breaks and causes the machine verifier to cry<br>in several cases, one of which being:<br><br>%RAX<def> = COPY %RCX<kill><br>%ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill><br><br>These subregister copies are together identified as noops, so are<br>both removed. However, the second one as it has an imp-use gets<br>converted into a kill:<br><br>%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill><br><br>As the original COPY has been removed, the verifier goes into tears<br>at the use of undefined EAX and RAX.<br><br><br>These implicit register operands after register allocation are quite<br>annoying and really hard to get right in a pass like this. They do<br>provide a more precise liveness tracking, but I don’t think that a<br>lot of targets actually benefit from the extra precision.<br></blockquote><br>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.).<br></div></blockquote><div><br></div><div>Yes, we would need to make sure that the scavenger works for ARM GPRs, even when they have GPRPair super-registers.</div><div><br></div><div>It would also constrain the late scheduler. Consider:</div><div><br></div><div><div>eax = def1</div><div>use1 eax</div><div>ax = def2</div><div>use2 eax</div><div><br></div></div><div>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:</div><div><div><br></div><div>ax = def2</div><div>use2 eax</div><div><div>eax = def1</div><div>use1 eax</div></div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>/jakob</div><div><br></div></div></div></body></html>