[PATCH] D60716: [DwarfDebug] Dump call site debug info into DWARF

Djordje Todorovic via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 31 04:26:58 PDT 2019


djtodoro marked 12 inline comments as done.
djtodoro added a comment.

@vsk Thanks for the comments!



================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:580
+  for (auto ArgReg : CallFwdRegsInfo->second)
+    ArgsRegsForProcess.insert(ArgReg.Reg);
+
----------------
vsk wrote:
> djtodoro wrote:
> > vsk wrote:
> > > Can we assert that this insertion into ArgsRegsForProcess occurs? I'm assuming that it's a bug if more than one argument is forward in the same register.
> > > 
> > > Super nit-pick, but, I don't think having 'ForProcess' in the name is very clear. Something like 'ForwardedRegWorklist' would be more in keeping with the naming in the rest of the compiler.
> > This only adds all the regs into the working list by iterating through the `CallSiteInfo`.
> > 
> > >Super nit-pick, but, I don't think having 'ForProcess' in the name is very clear. Something like 'ForwardedRegWorklist' would be more in keeping with the naming in the rest of the compiler.
> > 
> > Thanks!!
> I see. I had in mind:
> 
> ```
> bool InsertedReg = ForwardedRegWorklist.insert(ArgReg.Reg).second;
> assert(InsertedReg && "Single register used to forward two arguments?");
> ```
> 
> If this is already checked elsewhere, there's no need for a duplicate assert.
I see.. That makes sense.


================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:609
+          if (TRI->regsOverlap(FwdReg, MO.getReg()))
+            Defs.push_back(FwdReg);
+      }
----------------
vsk wrote:
> After FwdReg from MO is pushed into Defs, shouldn't this loop should break? IIUC no other registers should be equal-to/alias FwdReg.
Yes. Thanks!


================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:631
+    // forwarding registers or we finished the interpretation of all parameters.
+    if (I->isCall())
+      return;
----------------
vsk wrote:
> Should the basic block scan stop at branches in addition to calls to reduce compile time (MI::isCall() || MI::isBranch())?
Actually, that is not necessary, since this will never encounter a branch.


================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:632
+    if (I->isCall())
+      return;
+
----------------
vsk wrote:
> If the scan reaches a call or a branch, shouldn't it break instead of returning? That way, the ShouldTryEmitEntryVals case can be finished. Perhaps there should be a test?
If it encounters a call that means we can not consider the 'DW_OP_entry_value' as valid expression with in a call site parameter value, since the call may clobber that, and we stop the analysis as is.

There is a test for that part within the //test/DebugInfo/MIR/X86/dbgcall-site-interpretation.mir//.


================
Comment at: lib/CodeGen/AsmPrinter/DwarfExpression.cpp:479
+        emitUnsigned(Op->getArg(0));
+        emitSigned(Op->getArg(1));
+      } else {
----------------
vsk wrote:
> I don't understand the lowering of DW_OP_regx within addMachineRegExpression. Why should the lowering be different within/without parameter values? It seems like the DIExpression itself should be formed with DW_OP_bregx, if/when needed.
Yes, thanks! That is better way for sure.


================
Comment at: lib/CodeGen/TargetInstrInfo.cpp:1146
+      return None;
+    unsigned CastedOffset = static_cast<unsigned>(Offset);
+    if (Offset > 0)
----------------
vsk wrote:
> I do not think that casting the offset to unsigned is safe due to loss of precision. Also, note that the expression generated for the Offset=0 case is inefficient. Is there some way to reuse the code in DIExpression::appendOffset for this?
I agree, we can use the `DIExpression::appendOffset`.


================
Comment at: lib/Target/X86/X86InstrInfo.cpp:7452
+      Elements.push_back(dwarf::DW_OP_plus);
+    }
+
----------------
vsk wrote:
> We should be able to factor out the logic in DIExpression::{append,prepend}Offset to simplify this.
We can use that.


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

https://reviews.llvm.org/D60716





More information about the llvm-commits mailing list