This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen][RegAllocFast] Map PhysReg to its current VirtReg

Authored by cdevadas on Nov 22 2022, 11:05 AM.



It is not possible to have the one-to-one mapping for a
virtual register and the physical register allocated for
it during fast regalloc. Due to the in-place allocation,
a virtual register, while having multiple live ranges,
might get allocated to different physical registers. This
makes it impossible to map the physical register back to
its current live range inside the target hooks, like the
spill interface.

This patch introduces the physical register to the current
virtual register mapping whenever a physical register is
actually allocated.

Diff Detail

Event Timeline

cdevadas created this revision.Nov 22 2022, 11:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 22 2022, 11:05 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
cdevadas requested review of this revision.Nov 22 2022, 11:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 22 2022, 11:05 AM

This should replace the patch D134951 which used the delegate method for a specific purpose.
This is a more generic approach for targets to help identify the exact live range (virtual register) a physical register was currently assigned for.
While the allocation is in progress, this would serve the purpose of mapping a physical register to its virtual register.

cdevadas updated this revision to Diff 477539.Nov 23 2022, 9:47 AM
cdevadas edited the summary of this revision. (Show Details)

PhysToCurrentVirtReg should also be updated while reloading a physical register from the spill location. It happens when a RegMask (for instance, a function call) clobbers a register that is used in an instruction later in the BB. Also, at a BB entry, the LiveIn registers are reloaded. The reload point begins a new live range and it should be properly reflected in the mapping.

See the Usecase of PhysToCurrentVirtReg in D124196 (look for getPhysToCurrentVirtReg)

arsenm added inline comments.Nov 23 2022, 9:57 AM

Why pollute MRI with this, this is state local to RegAllocFast

The idea of mapping a physical register into the current virtual register in RegAllocFast would be likely a risky choice with a global variable. The same was true for the initial patch I posted D134951 which does the same thing specifically around the spill and reload functions via. the delegate.
The effort was to identify the physical register allocated for some special machine operands (whole-wave vector registers for AMDGPU), especially inside storeRegToStackSlot & loadRegFromStackSlot spill interfaces called from fast regalloc that directly spills the physRegs.
The better approach would be by passing an additional parameter (the virtual register) to the spiller interface. The interface is common to Greedy, PEI, and to some other places that have no use for this additional parameter. Still, I think it is the right way to handle the problem.


It should be accessible for targets and hence I thought MRI would be a feasible place.

Posted D138656 to pass the virtual register as an additional argument to the spiller interface. This review can be abandoned once D138656 gets approved.

cdevadas abandoned this revision.Dec 23 2022, 11:35 PM