[WIP][CodeGen] Modifying MBB's liveins representation as into regUnits #129847
Conversation
|
@llvm/pr-subscribers-llvm-regalloc @llvm/pr-subscribers-backend-arm Author: Vikash Gupta (vg0204) ChangesCurrently, the machine basicblock does not fully utilizes the laneBitmask associated with physReg liveIns to check for the precise liveness. Conservatively, it acts fully correct now, only if all liveIns check for MBB is in form it defines it for itself. So, now with the use of register units tracking for MBB's liveIns , its possible to track & check liveness for all sorts of physRegs. It is needed to handle #129848 Full diff: https://github.com/llvm/llvm-project/pull/129847.diff 3 Files Affected:
diff --git a/llvm/include/llvm/CodeGen/MachineBasicBlock.h b/llvm/include/llvm/CodeGen/MachineBasicBlock.h
index 2de96fa85b936..ab88177b63fed 100644
--- a/llvm/include/llvm/CodeGen/MachineBasicBlock.h
+++ b/llvm/include/llvm/CodeGen/MachineBasicBlock.h
@@ -13,6 +13,7 @@
#ifndef LLVM_CODEGEN_MACHINEBASICBLOCK_H
#define LLVM_CODEGEN_MACHINEBASICBLOCK_H
+#include "llvm/ADT/BitVector.h"
#include "llvm/ADT/DenseMapInfo.h"
#include "llvm/ADT/GraphTraits.h"
#include "llvm/ADT/SparseBitVector.h"
@@ -158,6 +159,7 @@ class MachineBasicBlock
MachineFunction *xParent;
Instructions Insts;
+ const TargetRegisterInfo *TRI;
/// Keep track of the predecessor / successor basic blocks.
SmallVector<MachineBasicBlock *, 4> Predecessors;
@@ -177,6 +179,10 @@ class MachineBasicBlock
using LiveInVector = std::vector<RegisterMaskPair>;
LiveInVector LiveIns;
+ /// Keeps track of live register units for those physical registers which
+ /// are livein of the basicblock.
+ BitVector LiveInRegUnits;
+
/// Alignment of the basic block. One if the basic block does not need to be
/// aligned.
Align Alignment;
@@ -458,11 +464,17 @@ class MachineBasicBlock
void addLiveIn(MCRegister PhysReg,
LaneBitmask LaneMask = LaneBitmask::getAll()) {
LiveIns.push_back(RegisterMaskPair(PhysReg, LaneMask));
+ addLiveInRegUnit(PhysReg, LaneMask);
}
void addLiveIn(const RegisterMaskPair &RegMaskPair) {
LiveIns.push_back(RegMaskPair);
+ addLiveInRegUnit(RegMaskPair.PhysReg, RegMaskPair.LaneMask);
}
+ // Sets the register units for Reg based on the LaneMask in the
+ // LiveInRegUnits.
+ void addLiveInRegUnit(MCRegister Reg, LaneBitmask LaneMask);
+
/// Sorts and uniques the LiveIns vector. It can be significantly faster to do
/// this than repeatedly calling isLiveIn before calling addLiveIn for every
/// LiveIn insertion.
@@ -484,6 +496,9 @@ class MachineBasicBlock
void removeLiveIn(MCRegister Reg,
LaneBitmask LaneMask = LaneBitmask::getAll());
+ /// Resets the register units from LiveInRegUnits for the specified regsiters.
+ void removeLiveInRegUnit(MCRegister Reg);
+
/// Return true if the specified register is in the live in set.
bool isLiveIn(MCRegister Reg,
LaneBitmask LaneMask = LaneBitmask::getAll()) const;
diff --git a/llvm/lib/CodeGen/MachineBasicBlock.cpp b/llvm/lib/CodeGen/MachineBasicBlock.cpp
index b3a71d1144726..0e5055d7bec2c 100644
--- a/llvm/lib/CodeGen/MachineBasicBlock.cpp
+++ b/llvm/lib/CodeGen/MachineBasicBlock.cpp
@@ -35,6 +35,7 @@
#include "llvm/IR/ModuleSlotTracker.h"
#include "llvm/MC/MCAsmInfo.h"
#include "llvm/MC/MCContext.h"
+#include "llvm/MC/MCRegisterInfo.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/Target/TargetMachine.h"
@@ -51,10 +52,12 @@ static cl::opt<bool> PrintSlotIndexes(
cl::init(true), cl::Hidden);
MachineBasicBlock::MachineBasicBlock(MachineFunction &MF, const BasicBlock *B)
- : BB(B), Number(-1), xParent(&MF) {
+ : BB(B), Number(-1), xParent(&MF),
+ TRI(MF.getSubtarget().getRegisterInfo()) {
Insts.Parent = this;
if (B)
IrrLoopHeaderWeight = B->getIrrLoopHeaderWeight();
+ LiveInRegUnits.resize(TRI->getNumRegUnits());
}
MachineBasicBlock::~MachineBasicBlock() = default;
@@ -597,6 +600,14 @@ void MachineBasicBlock::printAsOperand(raw_ostream &OS,
printName(OS, 0);
}
+void MachineBasicBlock::addLiveInRegUnit(MCRegister Reg, LaneBitmask LaneMask) {
+ for (MCRegUnitMaskIterator Unit(Reg, TRI); Unit.isValid(); ++Unit) {
+ LaneBitmask UnitMask = (*Unit).second;
+ if ((UnitMask & LaneMask).any())
+ LiveInRegUnits.set((*Unit).first);
+ }
+}
+
void MachineBasicBlock::removeLiveIn(MCRegister Reg, LaneBitmask LaneMask) {
LiveInVector::iterator I = find_if(
LiveIns, [Reg](const RegisterMaskPair &LI) { return LI.PhysReg == Reg; });
@@ -604,21 +615,32 @@ void MachineBasicBlock::removeLiveIn(MCRegister Reg, LaneBitmask LaneMask) {
return;
I->LaneMask &= ~LaneMask;
- if (I->LaneMask.none())
+ if (I->LaneMask.none()) {
LiveIns.erase(I);
+ removeLiveInRegUnit(I->PhysReg);
+ }
}
MachineBasicBlock::livein_iterator
MachineBasicBlock::removeLiveIn(MachineBasicBlock::livein_iterator I) {
// Get non-const version of iterator.
LiveInVector::iterator LI = LiveIns.begin() + (I - LiveIns.begin());
+ removeLiveInRegUnit(LI->PhysReg);
return LiveIns.erase(LI);
}
+void MachineBasicBlock::removeLiveInRegUnit(MCRegister Reg) {
+ for (MCRegUnit Unit : TRI->regunits(Reg))
+ LiveInRegUnits.reset(Unit);
+}
+
bool MachineBasicBlock::isLiveIn(MCRegister Reg, LaneBitmask LaneMask) const {
- livein_iterator I = find_if(
- LiveIns, [Reg](const RegisterMaskPair &LI) { return LI.PhysReg == Reg; });
- return I != livein_end() && (I->LaneMask & LaneMask).any();
+ for (MCRegUnitMaskIterator Unit(Reg, TRI); Unit.isValid(); ++Unit) {
+ LaneBitmask UnitMask = (*Unit).second;
+ if ((UnitMask & LaneMask).any() && LiveInRegUnits.test((*Unit).first))
+ return true;
+ }
+ return false;
}
void MachineBasicBlock::sortUniqueLiveIns() {
@@ -1751,12 +1773,14 @@ MachineBasicBlock::getEndClobberMask(const TargetRegisterInfo *TRI) const {
void MachineBasicBlock::clearLiveIns() {
LiveIns.clear();
+ LiveInRegUnits.reset();
}
void MachineBasicBlock::clearLiveIns(
std::vector<RegisterMaskPair> &OldLiveIns) {
assert(OldLiveIns.empty() && "Vector must be empty");
std::swap(LiveIns, OldLiveIns);
+ LiveInRegUnits.reset();
}
MachineBasicBlock::livein_iterator MachineBasicBlock::livein_begin() const {
diff --git a/llvm/test/CodeGen/ARM/aes-erratum-fix.ll b/llvm/test/CodeGen/ARM/aes-erratum-fix.ll
index 82f5bfd02a56e..e1361d6efa780 100644
--- a/llvm/test/CodeGen/ARM/aes-erratum-fix.ll
+++ b/llvm/test/CodeGen/ARM/aes-erratum-fix.ll
@@ -68,8 +68,8 @@ define arm_aapcs_vfpcc void @aese_via_call2(half %0, ptr %1) nounwind {
; CHECK-FIX-NEXT: push {r4, lr}
; CHECK-FIX-NEXT: mov r4, r0
; CHECK-FIX-NEXT: bl get_inputf16
-; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: vld1.64 {d16, d17}, [r4]
+; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: aese.8 q8, q0
; CHECK-FIX-NEXT: aesmc.8 q8, q8
; CHECK-FIX-NEXT: vst1.64 {d16, d17}, [r4]
@@ -89,8 +89,8 @@ define arm_aapcs_vfpcc void @aese_via_call3(float %0, ptr %1) nounwind {
; CHECK-FIX-NEXT: push {r4, lr}
; CHECK-FIX-NEXT: mov r4, r0
; CHECK-FIX-NEXT: bl get_inputf32
-; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: vld1.64 {d16, d17}, [r4]
+; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: aese.8 q8, q0
; CHECK-FIX-NEXT: aesmc.8 q8, q8
; CHECK-FIX-NEXT: vst1.64 {d16, d17}, [r4]
@@ -2222,8 +2222,8 @@ define arm_aapcs_vfpcc void @aesd_via_call2(half %0, ptr %1) nounwind {
; CHECK-FIX-NEXT: push {r4, lr}
; CHECK-FIX-NEXT: mov r4, r0
; CHECK-FIX-NEXT: bl get_inputf16
-; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: vld1.64 {d16, d17}, [r4]
+; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: aesd.8 q8, q0
; CHECK-FIX-NEXT: aesimc.8 q8, q8
; CHECK-FIX-NEXT: vst1.64 {d16, d17}, [r4]
@@ -2243,8 +2243,8 @@ define arm_aapcs_vfpcc void @aesd_via_call3(float %0, ptr %1) nounwind {
; CHECK-FIX-NEXT: push {r4, lr}
; CHECK-FIX-NEXT: mov r4, r0
; CHECK-FIX-NEXT: bl get_inputf32
-; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: vld1.64 {d16, d17}, [r4]
+; CHECK-FIX-NEXT: vorr q0, q0, q0
; CHECK-FIX-NEXT: aesd.8 q8, q0
; CHECK-FIX-NEXT: aesimc.8 q8, q8
; CHECK-FIX-NEXT: vst1.64 {d16, d17}, [r4]
|
There was a problem hiding this comment.
The changes to this file look correct - the vorr qN, qN, qN is necessary and has to be done to the input of the aes instruction pair, which it is still.
There was a problem hiding this comment.
This is missing most of the changes necessary to do this. We need a full migration away from the existing storage as reg + lane mask, to the register units. This requires MIR print and parsing changes, and I'm sure there will be downstream fallout in use sites
So, should I start this as separate task entirely? Also, don't we need MCphysReg mandatorily as part of liveIn representation too, as that is used entirely all over the llvm codegen, as regunits alone cannot hold that sense? Once we go into realm of regUnits, it would not be possible to know their exact source MCPhysReg, if not tracked parallely. Doesn't something like reg + liveRegUnit is better, as its still technically as same as reg + lane. Also, now rather than maintininng list of liveIn regs, we can maintain a set of all liveIn regUnits (basically union of liveRegUnit for all regs in MBB) |
|
Also, the liveIn registers represent physReg which need not be entirely live into MBB (so the laneMask makes sense), but migrating entirely into regUnits (representing only live parts of liveIn physRegs) could cause severe fallout as you mentioned at use sites. So, we strongly cannot eliminate the register concept as liveIn of MBB I fee! Could you through some light on it @arsenm! |
|
KInd Ping @arsenm ! |
|
This patch is about 5% of the changes required. This requires fully removing the existing block tracking in terms of physical registers. As a first step, I think you should address introduction of LiveRegUnitMasks. We need a new MachineOperand type, a MIR section to print a compacted regunit mask with an ID number for referencing in the instruction stream (similar to how frame indexes work). |
Just a brief of things I need to do as per my study (please let me know if anything is misunderstood) :
Did I miss anything @arsenm ? |
|
I guess those points are related work we need to move all infrastructure to work on register units. If you're just talking about changing the block live in representation, we can probably get away without it. We do need MIR print/parse changes for the liveins in terms of register units. It may or may not make sense to share code with regunit masks for that. |
If we want to achieve something like this, I am unable to see how can we get away from all steps mentioned, as I deduced those after back-tracking the usage of ID number referencing for FI in the instructions. Secondly, liveins as the regunit mask in someway (alongwith physReg) & representing them completely as register units apparently seems same but are 2 things as in the latter, the concept of liveins as physReg will vanish irreversibly causing significant downfall at use-site of |
This seems not difficult to do once the clarity on livein representation has been reached! |
|
Gentle ping @arsenm ! |
|
@arsenm , any final thoughts & suggestions on my doubts ? |
@arsenm don't you think it's as a big change (from its impact perspective, even not if implementation) that it can break everything, as unlike just introduction of optional laneBitmask to physeg, as supported now, is an extension which supported backward compatability, but this will need compulsory changes in every test files for all archs, as we are supposedly completely stripping physReg concept, replacing with regunits as block liveins , so what about this?
|
Hey @arsenm, if you could spare sometime and comment on this, it would be great! |
|
Could one solution be : We can store only the live regunits (for either of its root) as MCPhysReg in LiveInList using the its attached laneBitMask value provided (or entire Reg in case laneBitmask is set as All), rather than storing the laneBitMask as part of the LiveIn. For Example :
will be transformed into :
Does it make sense, along the line of my doubts just mentioned above? |
There is no compatibility concern, and every target will need to be updated. Just introducing a parallel structure with the same purpose is actively harmful. This is a full migration effort, I don't see how it makes sense for both livein representations to coexist. It will only provide a new source of inconsistency bugs and waste compile time maintaining both cases.
What do you mean by "significant downfall"? Conceptually I don't see why you should need to enumerate the live in registers frequently. Most uses care about whether the register is live or not
This is the whole point, re-encode the live-ins in terms of register units |
I haven't read carefully the whole thread, but I agree with this. |
|
Also, side question, what is the point of changing the liveins representation? |
I changed it as tracking of live-ins as regUnits (which are constant in number) rather than registers are quite less expensive. As the number of registers in arch like ourselves can go up as 9k due to aliasing & RegisterTuple stuff, which can be avoided due to exact nature of it |
As, I looked I think we need to make changes here to handle it : So, anyone taking care of it as of now, because its needed to be done for my work to move forward? |
No-one is working on it, as far as I know. |
Its quiet easy to achieve from implemetation point of view (cannot say the same if its have conceptually implication at big). So, I am just in the process of trying it locally. |
It's confusing and unclear how to interpret mixed aliasing register entries with the lanemasks. There's also a compile time cost every time we need to translate between the physical register representation and the actual liveness tracking in regunits. Since these are purely used for liveness, they should always be in terms of regunits |
It worked as expected, should I proceed with it as a PR for review @jayfoad ! |
Sure. |
vg0204
force-pushed
the
vg0204/add-liveRegUnit-compute-in-MBB
branch
from
4b91b83 to
a1b695d
Compare
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
| @@ -13,7 +13,9 @@ | |||
| #ifndef LLVM_CODEGEN_MACHINEBASICBLOCK_H | |||
| #define LLVM_CODEGEN_MACHINEBASICBLOCK_H | |||
|
|
|||
| #include "llvm/ADT/BitVector.h" | |||
| @@ -174,8 +176,7 @@ class MachineBasicBlock | |||
| std::optional<uint64_t> IrrLoopHeaderWeight; | |||
|
|
|||
| /// Keep track of the physical registers that are livein of the basicblock. | |||
| using LiveInVector = std::vector<RegisterMaskPair>; | |||
| LiveInVector LiveIns; | |||
| DenseSet<MCRegister> LiveIns; | |||
There was a problem hiding this comment.
I'm not sure if it's a good idea to change from std::vector to DenseSet. The patch would be less invasive if you just changed it to std:vector<MCRegister>
You should at least benchmark it using http://llvm-compile-time-tracker.com/. You can do this by asking @nikic to add your fork of LLVM, and then any branches you create called "perf/*" will automatically get benchmarked.
There was a problem hiding this comment.
I'm not sure if it's a good idea to change from std::vector to DenseSet. The patch would be less invasive if you just changed it to std:vector
It makes sense so aliasing registers (or tuples) will have common regunits (or their roots) to track them uniquely (in set) and check for isLiveIn would be cheaper.
You should at least benchmark it using http://llvm-compile-time-tracker.com/. You can do this by asking @nikic to add your fork of LLVM, and then any branches you create called "perf/*" will automatically get benchmarked.
Sure!
There was a problem hiding this comment.
@nikic can you add my forked repo https://github.com/vg0204/llvm-project.git for benchmarking it!
There was a problem hiding this comment.
It makes sense so aliasing registers (or tuples) will have common regunits (or their roots) to track them uniquely
Right, but the existing code already did that by calling sortUniqueLiveIns after adding all the individual livein registers. Changing to a set might be better, but it should be done as an orthogonal change (either before or after this patch) and it should be benchmarked.
llvm/lib/CodeGen/LiveRegUnits.cpp
Outdated
| @@ -88,7 +88,7 @@ void LiveRegUnits::accumulate(const MachineInstr &MI) { | |||
| static void addBlockLiveIns(LiveRegUnits &LiveUnits, | |||
| const MachineBasicBlock &MBB) { | |||
| for (const auto &LI : MBB.liveins()) | |||
| LiveUnits.addRegMasked(LI.PhysReg, LI.LaneMask); | |||
| LiveUnits.addRegMasked(LI, LaneBitmask::getAll()); | |||
There was a problem hiding this comment.
Further simplification is possible here, since this is the only call to addRegMasked so it no longer needs a Mask argument.
There was a problem hiding this comment.
Further simplification is possible here, since this is the only call to addRegMasked so it no longer needs a Mask argument.
Yes, agreed, for that, addRegmasked requires a default lanemask arg which is not the current case!
llvm/lib/CodeGen/MIRPrinter.cpp
Outdated
| OS << LS << printReg(LI.PhysReg, &TRI); | ||
| if (!LI.LaneMask.all()) | ||
| OS << ":0x" << PrintLaneMask(LI.LaneMask); | ||
| bool First = true; |
There was a problem hiding this comment.
You should continue to use LS instead of First. You only need to remove the part that prints the lanemask.
There was a problem hiding this comment.
This is new to me, as it might have happened when rebased the tip on latest llvm main. But, noted!
| Classes[Reg] = reinterpret_cast<TargetRegisterClass *>(-1); | ||
| KillIndices[Reg] = BBSize; |
There was a problem hiding this comment.
Don't change the Reg.id() part. It just makes the patch bigger and harder to review.
| OS << LS << printReg(LI.PhysReg, TRI); | ||
| if (!LI.LaneMask.all()) | ||
| OS << ":0x" << PrintLaneMask(LI.LaneMask); | ||
| for (const MCRegister Reg : liveins()) { |
There was a problem hiding this comment.
Remove the const. (Pointers to const and const references are good, but plain const is not.)
There was a problem hiding this comment.
Another reason not to use DenseMap: the iteration order here will be undefined, so we will get spurious differences in MIR output printing.
| LaneMask |= J->LaneMask; | ||
| Out->PhysReg = PhysReg; | ||
| Out->LaneMask = LaneMask; | ||
| if(!Reg.isPhysical()) |
There was a problem hiding this comment.
This should be an assert
It caused failure for 2-3 LIT testcases, as its invoked at few places for MCRegs(which are virtRegs as assigned by MRI), not MCPhysReg. As you can see asserted at other livein-related API's!
There was a problem hiding this comment.
I raised #140527 for this. If you find other problems like this, please take the time to raise a separate PR to fix them, so that this PR stays focussed on doing one thing.
| if (I == LiveIns.end()) | ||
| return I; | ||
|
|
||
| DenseSet<MCRegister>::iterator start = LiveIns.begin(); | ||
| while (start != I) | ||
| start++; | ||
| MachineBasicBlock::livein_iterator next = start; | ||
| LiveIns.erase(start); | ||
| return next++; |
There was a problem hiding this comment.
This is pretty horrible and I'm not sure it works.
Either leave liveins as a std::vector, in which case this code does not need to change.
Or remove this method altogether. It is only used in one place, in X86FloatingPoint, and that code can ber rewritten to do this in some other way.
There was a problem hiding this comment.
Agreed!
Or remove this method altogether. It is only used in one place, in X86FloatingPoint, and that code can ber rewritten to do this in some other way.
Does this alternative make sense using make_early_inc_range
static unsigned calcLiveInMask(MachineBasicBlock *MBB, bool RemoveFPs) {
unsigned Mask = 0;
for (auto &I : llvm::make_early_inc_range(MBB->liveins())) {
MCPhysReg Reg = *I;
static_assert(X86::FP6 - X86::FP0 == 6, "sequential regnums");
if (Reg >= X86::FP0 && Reg <= X86::FP6) {
Mask |= 1 << (Reg - X86::FP0);
if (RemoveFPs) {
MBB->removeLiveIn(I);
continue;
}
}
}
return Mask;
}
| } | ||
|
|
||
| Register | ||
| MachineBasicBlock::addLiveIn(MCRegister PhysReg, const TargetRegisterClass *RC) { | ||
| assert(getParent() && "MBB must be inserted in function"); | ||
| assert(PhysReg.isPhysical() && "Expected physreg"); | ||
| assert(PhysReg && "Expected physreg"); |
There was a problem hiding this comment.
I might have overlooked to revert it, while trying different solutions locally. I'll take care of it!
2000 is still a lot! We need to understand which ones only fail because the way liveins are printed in MIR has changed (these ones can simply be updated) and which ones actually have different codegen, or fail in some other way. |
|
There are genuine codegen differences in: Looks like |
|
Rebasing on #140248 should fix one of 2000 failures. |
|
There are codegen diffs in |
|
@jayfoad , what I feel is that, lets deal with MIR-print(related to livein) changes (2k LIT tests basically) first which comprises about surely 80-85% test cases, then incrementally look into other tests causing codegen diff as few examples given by you and track them separately. Sounds Good? One last thing which I asked previously also, its fine to have these many file changes in single PR, from review as well tracking perspective? |
There are observed only 2 types of failure:
|
Currently, the machine basicblock does not fully utilizes the laneBitmask associated with physReg liveIns to check for the precise liveness. Conservatively, it acts fully correct now, only if all liveIns check for MBB is in form it defines it for itself. So, now with the use of register units tracking for MBB's liveIns , its possible to track & check liveness for all sorts of physRegs.
But, doesn't it make incorporates use of lanemask in livein, which is eventually non-exisistent in my patch! |
vg0204
force-pushed
the
vg0204/add-liveRegUnit-compute-in-MBB
branch
from
a1b695d to
a71dc1b
Compare
The reason for doing #140248 is that it makes |
I took a look at The RISCV example is: This has been discussed before: #96146, #95926 (comment) We need a proper solution for this issue before continuing with the current patch. |
Yes! There is one more scenario, that's not considered in this discussion when regunits are same despite different registers, when supperegs is composed of only addressable subregs. For example: in X86, both EAX and RAX have same set of regunits (HAX, AH, AL), as RAX (64bits) has got lower 32 bit subreg i.e. EAX & got nothing to represent upper 32bits. As in #96146, fake high regunits can now be seen. Such instance is quite commonplace. Its same as Qn & Dn case, but it's been handled as for now using artificial HI parts. I think as per current implementation the regunits are something that really not register composed of uniquely, but are the bare minimum chunks that can represent aliasing and overlaps (for addressable parts only OR defined fake parts) in registers. What do you think, as its make migration to regunit itself a very tricky thing in general. |
Currently, the machine basicblock does not fully utilizes the laneBitmask associated with physReg liveIns to check for the precise liveness. Conservatively, it acts fully correct now, only if all liveIns check for MBB is in form it defines it for itself.
So, now with the use of register units tracking for MBB's liveIns , its possible to track & check liveness for all sorts of physRegs.