LiveRangeCalc: Don't start liveranges of PHI instruction at the block begin.

[MatzeB]

Summary

Letting them begin at the PHI instruction slightly simplifies the code
but more importantly avoids breaking the assumption that live ranges
starting at the block begin are also live at the end of the predecessor
blocks. The MachineVerifier checks that but was apparently never run in
the few instances where liveranges are calculated for machine-SSA
functions.

[qcolombet]

Hi Matthias,

I am not sure this is the right thing to do.
Because of this change, we would have an order in phi definitions whereas there is in fact none.

That may make the machine verifier code more complicated, but I think this is what need to be fixed.

What do you think?

Thanks,
-Quentin

[MatzeB]

I don't think it really matters one way or another. Given code that looks like this:

100B BB#XX ...
116B %vreg1 = PHI %vreg8, %vreg42
132B %vreg2 = PHI %vreg42, %vreg8
...

previously the liveranges for vreg1 and vreg2 would start at 100B, with my patch they start at 116B/132B.

• Starting the range at 100B is closer to the reality of values living into the block and PHIs not really being instructions.
• Starting the range at 100B is contrary to the fact that the definition points of %vreg1/%vreg2 are at 116B/132B.
• Either way %vreg1 and %vreg2 interfere so we should be fine in this regard.
• The problem that motivated my change: We maintain an SSA representation for our liverange segments which have value numbers assigned. In case multiple value numbers reach a block we create a new one and let the live segment start at the block begin (you could call that an implicit PHI). This situation looks exactly the same as the case with PHI instructions, although it is not! The values that are picked in the predecessors are from %vreg8/%vreg42 which is in a different liveranges.

The last point would break the MachineVerifier (if it would actually run here) and breaks new code I am writing right now because I need a way to differentiate between "implicit PHIs" from live segment joins and live ranges started by PHI instructions. I could not think of a reason why letting live ranges start at the phi instructions would be bad, so I sent out the patch to get some opinions.

• Matthias

PS: CC to Andy, maybe he has some comments for this.

llvm/trunk/lib/CodeGen/LiveRangeCalc.cpp

void LiveRangeCalc::reset(const MachineFunction *mf,
   resetLiveOutMap();
   LiveIn.clear();
 }
 
 
 static void createDeadDef(SlotIndexes &Indexes, VNInfo::Allocator &Alloc,
                           LiveRange &LR, const MachineOperand &MO) {
     const MachineInstr *MI = MO.getParent();
-    SlotIndex DefIdx;
-    if (MI->isPHI())
-      DefIdx = Indexes.getMBBStartIdx(MI->getParent());
-    else
-      DefIdx = Indexes.getInstructionIndex(MI).getRegSlot(MO.isEarlyClobber());
+    SlotIndex DefIdx =
+        Indexes.getInstructionIndex(MI).getRegSlot(MO.isEarlyClobber());
 
     // Create the def in LR. This may find an existing def.
     LR.createDeadDef(DefIdx, Alloc);
 }
 
 void LiveRangeCalc::calculate(LiveInterval &LI) {
   assert(MRI && Indexes && "call reset() first");