This is an archive of the discontinued LLVM Phabricator instance.

[VirtRegRewriter] Eliminate COPYs before re-writing by renaming.
AbandonedPublic

Authored by gberry on Oct 6 2016, 2:37 PM.

Details

Reviewers
qcolombet
MatzeB
Summary

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.

Event Timeline

gberry updated this revision to Diff 73853.Oct 6 2016, 2:37 PM
gberry retitled this revision from to [VirtRegRewriter] Eliminate COPYs before re-writing by renaming..
gberry updated this object.
gberry added reviewers: MatzeB, qcolombet.
gberry added subscribers: jonpa, mcrosier, junbuml, llvm-commits.
qcolombet edited edge metadata.Oct 6 2016, 3:31 PM

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

gberry added a comment.Oct 7 2016, 8:36 AM

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?

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 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

gberry planned changes to this revision.Oct 10 2016, 2:11 PM

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.

gberry updated this revision to Diff 75202.Oct 19 2016, 12:38 PM
gberry edited edge metadata.

Update algorithm to be more contained w.r.t. kill flag updating

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.

qcolombet added inline comments.Nov 10 2016, 4:37 PM
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.
It would greatly simplify add/removeMappedPhysReg.

227

We could gate that dependency on DisableRenameCopys.
That being said, if we move all that code in its own pass, that's not going to be a problem :).

305

Seems inefficient to use a vector here.
At the very least it should be sorted.

345

Looks to me like this is reimplementing functionalities already available in the LiveRegMatrix class.
Reuse that instead.

437

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.

500

Add && "Msg" in the assert.

Also explain in the comment before the assert what would it take to extend that to multiple VNs.

MatzeB edited edge metadata.Nov 11 2016, 10:27 AM

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
402–403

Try MachineRegisterInfo::hasOneDef(), LiveRange::constainsOneValue() seems to also count invalid VNInfos and I am not sure those are all cleared here.

410–414

Isn't that the same as VReg and should rather be assert(CopyDst.getReg() == VReg);

419–420

This needs to adjust to subregister indexes on the dest/source operand!

429

!TargetRegisterInfo::isVirtualRegister -> isPhysicalRegister that also avoids hitting NoReg (though not a problem in this case).

440

Call it MO instead of Opnd like most of the code?

451

Isn't &OpndInst.getOperand(1) == &Opnd always true and can be an assert?

453–456

What about subregister indexes?

gberry abandoned this revision.Nov 18 2016, 2:16 PM

This work has been superseded by

r287070 [RegAllocGreedy] Record missed hint for late recoloring

and other follow-on changes.