[PATCH] D96045: [llvm-dwarfdump][locstats] Unify handling of inlined vars with no loc

Jeremy Morse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 4 09:22:42 PST 2021


jmorse added a comment.

Thanks for the patch -- do I understand correctly that any coverage of an inlined variable will lead to it being removed from the "InlinedVariables" vector? I'm wondering what happens if we have two inlining sites: one where an inlined variable is optimised out, another where the variable has a location. If we're keeping global data and deleting elements from it when coverage is observed, I think that'll make the output dependent on which the inlining sites are encountered.

If a site without coverage is seen before a site with coverage, it'll get a zero-coverage record from InlinedVariables successfully. But if you flip the order, the site with coverage will erase from InlinedVariables, and the site without coverage won't know about the un-covered variable.

I think this patch also relies on the abstract DW_AT_inline copy of the subprogram being encountered before any call sites, I don't know that that's guaranteed. (Fix this is probably hard, hence I uh, avoided looking at this).



================
Comment at: llvm/tools/llvm-dwarfdump/Statistics.cpp:30
+/// This represents variables DIE offsets.
+using InlinedVarsTy = std::vector<uint64_t>;
+/// This maps function DIE offset to its variables.
----------------
Nit, this can probably be a SmallVector, right?


================
Comment at: llvm/tools/llvm-dwarfdump/Statistics.cpp:539-540
+
+  // After we processed all vars of the inlined function,
+  // we want to know how many variables has no location.
+  constexpr unsigned ZeroCoverageBucket = 0;
----------------



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96045



More information about the llvm-commits mailing list