[PATCH] D88896: [DebugInfo][InstrRef][3/4] Produce DBG_INSTR_REFs for all* variable locations
Orlando Cazalet-Hyams via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 1 05:55:08 PDT 2021
Orlando added a comment.
I've taken a stab at reviewing this. I especially appreciate and enjoy the detailed comments and patch description. I've left some nits and questions inline but otherwise it looks good IMO.
================
Comment at: llvm/include/llvm/CodeGen/MachineFunction.h:510
+ /// value, or None if nothing could be recovered.
+ Optional<DebugInstrOperandPair> salvageCopySSA(MachineInstr &MI);
+
----------------
Does this need to return an `Optional`? As far as I can tell `salvageCopySSA` never returns `None`, and the only callsite doesn't check whether the returned result has a value or not.
================
Comment at: llvm/lib/CodeGen/MachineFunction.cpp:1039-1040
+ Offset = TRI.getSubRegIdxOffset(SubReg);
+ if (OldRegBits >= NewRegBits || Offset)
+ SubReg = 0;
+
----------------
I'm struggling to follow this part. When you say "only remember truncations or offsets" am I right in thinking that setting `SubReg = 0` causes some kind of mismatch that is picked up and handled by LiveDebugValues/InstrRefBasedImpl in D88894?
================
Comment at: llvm/lib/CodeGen/MachineFunction.cpp:1133-1140
+ auto Builder = BuildMI(TargetBB, TargetBB.getFirstNonPHI(), DebugLoc(),
+ TII.get(TargetOpcode::DBG_PHI));
+ Builder.addReg(State.first);
+ unsigned NewNum = getNewDebugInstrNum();
+ Builder.addImm(NewNum);
+ MachineInstr *NewInst = Builder;
+ NewInst->getOperand(0).setIsDebug(true);
----------------
Is it worth putting the create-a-dbg-phi code into a function that is shared between these patches? No strong opinion on this.
================
Comment at: llvm/lib/CodeGen/MachineFunction.cpp:1139
+ MachineInstr *NewInst = Builder;
+ NewInst->getOperand(0).setIsDebug(true);
+ return ApplySubregisters({NewNum, 0u});
----------------
nit: I think you can do `Builder.addReg(State.first, RegState::Debug)` on line 1135 instead.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:776
+ // SelectionDAG when more information is available.
+ auto EmitHalfDoneInstrRef = [&](unsigned VReg) -> MachineInstr * {
+ auto MIB = BuildMI(*MF, DL, RefII);
----------------
SGTM. I make a comment later about moving the SelectionDAGISel half-done-dbg-instr-fixup code into its own function. If you do that you could change `and patch it up later in SelectionDAG` to `and patch it up later in <function-name>`, which might make it easier to quickly find the relevant code in the future.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/InstrEmitter.h:121-128
+ /// Emit a DBG_VALUE $noreg, indicating a variable has no location.
+ MachineInstr *EmitDbgNoLocation(SDDbgValue *SD);
+
+ /// Emit a DBG_VALUE %stack, referring to a frame index.
+ MachineInstr *EmitDbgFrameIndex(SDDbgValue *SD);
+
+ /// Emit a DBG_VALUE of some constant value.
----------------
It might be useful to split the factoring-out of this DBG_VALUE building code from `EmitDbgValue` into a separate NFC patch IMO, but it's a probably not too important.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:646-700
+ auto MakeDbgValue = [&](MachineInstr &MI) {
+ const MCInstrDesc &RefII = TII->get(TargetOpcode::DBG_VALUE);
+ MI.setDesc(RefII);
+ MI.getOperand(1).ChangeToRegister(0, false);
+ MI.getOperand(0).setIsDebug();
+ };
+
----------------
I think it would be good to move this fixup-half-done-instr-refs code into its own function. It would reduce clutter in `runOnMachineFunction` and you could then also add a comment to the `EmitHalfDoneInstrRef ` lambda mentioning it so that it's easy to find from there. wdyt?
================
Comment at: llvm/test/DebugInfo/X86/instr-ref-selectiondag.ll:83
+
+;; Don't test the location of these instr-refs, only that the three non-argument
+;; dbg.values become DBG_INSTR_REFs. We previously checked that these numbers
----------------
Sorry if this is mentioned elsewhere - why are you explicitly not testing the location (position?) of the isntr-refs here?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88896/new/
https://reviews.llvm.org/D88896
More information about the llvm-commits
mailing list