[PATCH] D154080: [DebugInfo][RemoveDIs] Add conversion utilities between dbg.value form and DPValue new-debug-info form

[Jeremy Morse via Phabricator via llvm-commits]

jmorse added a comment.

Looking at the history-diff, I've also added some flag-maintenance in IRMover, which I believe is involved in moving modules around. I think there were just a few code paths there where we start constructing replacement modules/functions, and have to start off with the flag being correct. (This is all cost+overhead of having the two implementations available right now).

I've also added a createMarker method for iterators, to ease the creation of TrailingDPValue records and for when we're not completely sure if we're inserting at end() or not.



================
Comment at: llvm/lib/IR/BasicBlock.cpp:57
+    assert(!I.DbgMarker && "DbgMarker already set on old-format instrs?");
+    if (DbgValueInst *DVI = dyn_cast<DbgValueInst>(&I)) {
+      // Convert this dbg.value to a DPValue.
----------------
Orlando wrote:
> What about other debug intrinsics? What's the plan for those?
Later patches, basically. As this is being staged-in incrementally, we can get a totally-working implementation that only operates on dbg.values (which represent the most complicated problems to solve) and then naturally extend to dbg.declare, dbg.assign, dbg.label and pseudo probes.


================
Comment at: llvm/lib/IR/BasicBlock.cpp:236-238
+  for (auto &Inst : *this) {
+    if (!Inst.DbgMarker)
+      continue;
----------------
Orlando wrote:
> This pattern is used in a few places. Could be worth using a `filter_iterator` (`llvm::make_filter_range` etc), similar to what `instructionsWithoutDebug()` does, that skips instructions without debug markers? YMMV.
> 
> e.g.
> 
> `for (auto &Inst : instructionsWithDebugMarkers())`
I've been trying to steer clear of that for the moment, to make it harder to write things that rely on implementation details. That'll discourage us using such things like filter iterators in the optimisation passes in favour of proving APIs into/out-of the core classes that Do Things (TM). That then means we can decouple optimisations from how things are stored, making it easier to test out different storage models.


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

https://reviews.llvm.org/D154080