[PATCH] D62904: [DebugInfo] Honour variable fragments in LiveDebugValues

David Stenberg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 7 08:36:55 PDT 2019


dstenb added inline comments.


================
Comment at: lib/CodeGen/LiveDebugValues.cpp:842
+
+  // If there is no fragment, then no other use of the variable has a fragment
+  // either. We can ignore the variable.
----------------
jmorse wrote:
> dstenb wrote:
> > Is this guaranteed due to how SROA and other IR passes behave?
> > 
> > Would it cost a lot to drop this assumption and handle mixes of fragmented and non-fragmented debug values?
> It's my belief that that's how SROA works, but I don't think it's a documented guarantee. SROA::splitAlloca certainly seems to completely rewrite dbg.declare's into ones that all use fragments. The verifier doesn't attempt to enforce this rule though. Most of this belief is due to running into this assertion [0] several times, which fires if you get a mix of fragment/non-fragment variable locations in a DebugLocEntry.
> 
> I've run a quick test in this function, maintaining a static set of Variable/InlinedAt pairs that have been seen without fragments, and asserting that they're never seen _with_ fragments. This doesn't fire on a build of clang-3.4, which gives me some confidence the guarantee exists.
> 
> If it turns out a mixture needs to be supported, it'd be easy to interpret the nonfragmented debug values as covering the whole variable, it should Just Work (TM).
> 
> [0] https://github.com/llvm/llvm-project/blob/2028ae975c6aa65df3d89c10c95bf9b7baa5e0ab/llvm/lib/CodeGen/AsmPrinter/DebugLocEntry.h#L131
> Most of this belief is due to running into this assertion [0] several times, which fires if you get a mix of fragment/non-fragment variable locations in a DebugLocEntry.

Oh, under which circumstances have you hit that assert? (Or was that supposed to say //not//?)

At least on trunk `DbgEnitityHistoryCalculator` should close all open fragmented debug values when encountering a non-fragment debug value, and vice versa. `DwarfDebug::buildLocationList()` should respect those ending indices, so it "should" not be possible to land in that assertion even if the MIR contains a mix of fragmented and non-fragmented locations.

(I noticed that the commit in [0] is a bit older, but there I think the same logic holds since we in `DwarfDebug::buildLocationList()` used `fragmentsOverlap()` to close all preceding locations?)


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

https://reviews.llvm.org/D62904





More information about the llvm-commits mailing list