This adds a simple copy propagation pass to VirtRegRewriter that uses
LiveIntervals to find COPYs whose destination can be renamed allowing
the COPY to be eliminated when doing so would be beneficial.
Details
Diff Detail
- Build Status
Buildable 633 Build 633: arc lint + arc unit
Event Timeline
Hi Geoff,
Disclaimer: I haven't looked at the patch, just a comment.
I would rather fix the MachineCopyPropagation pass than adding this logic to this pass.
Why aren't we catching those cases in the MachineCopyPropagation pass?
Cheers,
-Quentin
Hi Quentin,
I believe this was discussed before here: https://reviews.llvm.org/D20531. In this change, the COPYs only become removable as the result of renaming/recoloring their destination registers. I thought the consensus was that this recoloring was only safe to do with virtual registers to avoid violating ABI/other register constraints. The COPYs that this change catches are mostly only removable after register allocation since they are only removable once live range splitting/spilling has occurred.
Hi Quentin,
I've discovered a problem with this change that I am in the middle of addressing. Unfortunately, I'm going to be out for the rest of the week, so I won't be able to upload a new version until sometime next week.
Hi Quentin (and anyone else interested),
I just uploaded a new version that fixes the last issue that I am aware of and also simplifies the algorithm a bit. Please take a look when you get a chance.
Hi Geoff,
I'll have a look by the end of the week.
I still worried by having so much logic in the rewriter, it feels wrong to me. I'll check what happen in the alloc to see if we could catch that there.
Cheers,
-Quentin
Hi Quentin,
Thanks. FWIW, I could split this out into a separate pass that optionally runs just before VirtRegRewriter if that is more desirable.
Hi Geoff,
I could split this out into a separate pass that optionally runs just before VirtRegRewriter if that is more desirable.
Yes, that's more desirable.
Thanks,
Q.
lib/CodeGen/VirtRegMap.cpp | ||
---|---|---|
158 | For consistency with the rest of LLVM source code I would use typedef. | |
158 | Having read the code now, I believe it would be more efficient to map PhysReg to LI. | |
221 | We could gate that dependency on DisableRenameCopys. | |
296 | Seems inefficient to use a vector here. | |
336 | Looks to me like this is reimplementing functionalities already available in the LiveRegMatrix class. | |
428 | Wasn't the goal to propagate useless copies, i.e., that should always be beneficial, right? If you want to do more, then please add test cases covering that. Indeed, as far as I can tell, the changes in the test cases only cover the simple case of propagating useless copies. | |
491 | Add && "Msg" in the assert. Also explain in the comment before the assert what would it take to extend that to multiple VNs. |
I just read the main function to understand the purpose, comments below.
So my understanding is that this looks for
%vreg0 = COPY %vreg1
with vreg0 assigned different from vreg1 but where it is possible to use the vreg1's register for vreg0 as well without any interference?
This obviously needs to buildup new interference checking infrastructure. Why not do this as part of RegAlloc when LiveRegMatrix is still around?
lib/CodeGen/VirtRegMap.cpp | ||
---|---|---|
393–394 | Try MachineRegisterInfo::hasOneDef(), LiveRange::constainsOneValue() seems to also count invalid VNInfos and I am not sure those are all cleared here. | |
401–405 | Isn't that the same as VReg and should rather be assert(CopyDst.getReg() == VReg); | |
410–411 | This needs to adjust to subregister indexes on the dest/source operand! | |
420 | !TargetRegisterInfo::isVirtualRegister -> isPhysicalRegister that also avoids hitting NoReg (though not a problem in this case). | |
431 | Call it MO instead of Opnd like most of the code? | |
442 | Isn't &OpndInst.getOperand(1) == &Opnd always true and can be an assert? | |
444–447 | What about subregister indexes? |
This work has been superseded by
r287070 [RegAllocGreedy] Record missed hint for late recoloring
and other follow-on changes.
For consistency with the rest of LLVM source code I would use typedef.