[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