[PATCH] D40413: [CodeExtractor] Add debug locations for new call and branch instrs.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 5 13:39:46 PST 2017


fhahn added inline comments.


================
Comment at: lib/Transforms/Utils/CodeExtractor.cpp:1050
+      }
+    assert(BranchI->getDebugLoc() && "Could not find debug location in header");
+  }
----------------
rriddle wrote:
> fhahn wrote:
> > fhahn wrote:
> > > aprantl wrote:
> > > > This assertion will fail if you haved a nodebug function inlined into a function with debuginfo.
> > > Ah yes, I will look into how the inliner deals with that case and handle it appropriately.
> > The basic block `header` is from a function with debug info (it comes from `oldFunction`). Isn't it save to assume that instructions in this basic block should have debug info? Do you mean when inlining a nodebug function in one with debug info, some basic blocks could be missing debug info which could trigger this assertion in the partial inliner? (Sorry my knowledge of the assumptions  about debug info are quite light).
> It's not safe to assume that the header block will have debug locations. So it should probably just find the first valid debug location, if there is one, and use that for the call instruction. It's only needed if there is a valid debug location in the abstracted blocks anyways.
> 
> For nodebug functions that are inlined, all of the instructions being inlined inherit the debug location of the call. If there are missing debug locations due to that, then the function was already missing debug info on some instructions.
Ah thanks for confirming. That makes things slightly more tricky. What is the suggested way to find the "first" valid debug location? BFS through the CFG? Could it happen that  `getSubprogram()` is not null, but there are no debug locations?


https://reviews.llvm.org/D40413





More information about the llvm-commits mailing list