[PATCH] D112133: [DebugInfo][Instr] Track subregisters across stack spills/restores

Orlando Cazalet-Hyams via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 20 10:16:52 PDT 2021


Orlando added a comment.

I think this looks good (the patch sounds great), but I definitely need to go over it at least once more before approving to be sure I understand the changes. In amongst the inline nits there are a couple of questions.



================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:751
+      LocIdxToLocID[Idx] = L;
+      // Initialize to PHI value; corresponds to the locations live-in value
+      // during transfer function construction.
----------------
nit: location's


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:1201
+    // and then spilt.
+    unsigned CandidateSizes[] = {64, 32, 16, 8};
+    Optional<ValueIDNum> Result = None;
----------------
`std::array` here could be preferable so the `size` can be used in the loop below?


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:1383
+  // Strictly limit ourselves to plain loads and stores, not all instructions
+  // that can access the stack. Fetch the frame index too.
+  int FI = -1;
----------------
nit: Is `FI` used anywhere else after these `isXXFromStackSlotPostFE` calls? The comment above makes it sound like the answer is yes, but I can't see it being used anywhere.


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.cpp:1457
+    // subregisters in the destination register line up with positions in the
+    // stack slot.
 
----------------
Is this an assumption that needs to be chceked in an `assert`, or is it that it's handled gracefully / won't cause a catastrophe if it is ever wrong?


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:288
 /// or debug registers. To avoid doing so, MLocTracker has several layers of
-/// indirection going on, with two kinds of ``location'':
-///  * A LocID uniquely identifies a register or spill location, with a
-///    predictable value.
-///  * A LocIdx is a key (in the database sense) for a LocID and a ValueIDNum.
-/// Whenever a location is def'd or used by a MachineInstr, we automagically
-/// create a new LocIdx for a location, but not otherwise. This ensures we only
-/// account for locations that are actually used or defined. The cost is another
-/// vector lookup (of LocID -> LocIdx) over any other implementation. This is
-/// fairly cheap, and the compiler tries to reduce the working-set at any one
-/// time in the function anyway.
+/// indirection going on, described below, to avoid un-necessarily tracking
+/// any location.
----------------
nit: unnecessarily


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:350
+  /// Unique-ification of spill. Used to number them -- their LocID number is
+  // the index in SpillLocs minus one plus NumRegs.
   UniqueVector<SpillLoc> SpillLocs;
----------------
nit: missing the 3rd `/` in `///`


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:362
+  /// slot that can take on the value of a subregister, when a super-register
+  // is written to the stack.
+  unsigned NumSlotIdxes;
----------------
nit: missing the 3rd `/` in `///`


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:373
+  /// bits, then the offset.
+  typedef std::pair<unsigned short, unsigned short> StackSlotPos;
+
----------------
Seems like it could be easy to mix up the fields in a pair of identical types. If this could be implemented as a struct without too much boilerplate I'd be slightly in favour of going down that route, but this isn't a strong opinion / request.


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:435
+  /// \param Spill The number of the spill we're fetching the location for.
+  /// \apram SpillIdx size/offset within the spill slot to be addressed.
+  unsigned getLocID(SpillLocationNo Spill, StackSlotPos Idx) {
----------------
nit: apram -> param


================
Comment at: llvm/lib/CodeGen/LiveDebugValues/InstrRefBasedImpl.h:458
+    assert(ID >= NumRegs);
+    ID -= NumRegs;
+    ID /= NumSlotIdxes;
----------------
I am a little confused with the large number of different indices flying around in here, so this might be a silly question. Should there be another number subtracted here, equivalent to the `Idx` added to the ID in the function above (`getSpillIDWithIdx`)? Or is this auto-magically handled due to integer division rounding or something?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112133/new/

https://reviews.llvm.org/D112133



More information about the llvm-commits mailing list