[PATCH] D101025: [llvm-dwarfdump] Fix inline function stats calculation

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro added inline comments.


================
Comment at: llvm/tools/llvm-dwarfdump/Statistics.cpp:467-468
+      Die.find(dwarf::DW_AT_abstract_origin) != None;
+  const bool IsFunction =
+      ((Tag == dwarf::DW_TAG_subprogram) && !HasAbstractOriginAttr);
   const bool IsBlock = Tag == dwarf::DW_TAG_lexical_block;
----------------
dblaikie wrote:
> "IsPotentialAbstractOrigin"?
Does this stand for the lines 465,466? (I guess it does)


================
Comment at: llvm/tools/llvm-dwarfdump/Statistics.cpp:470-472
+  const bool IsInlinedFunction =
+      (Tag == dwarf::DW_TAG_inlined_subroutine ||
+       (Tag == dwarf::DW_TAG_subprogram && HasAbstractOriginAttr));
----------------
dblaikie wrote:
> This name and the associated names (InlineFnsToBeProcessed, etc) may be incorrect now?
> 
> (or it looks like, if we're tracking "InlinedVars" Separately, perhaps this variable is the wrong one for tracking those - yeah, judging by the statistics that have changed - we probably shouldn't be grouping these non-inline concrete definitions under the "#inlined functions" or "#inlined functions with abstract origins" (also not sure why we have those two different statistics - inlined functions without abstract origins are non-DWARF-conforming, I think)
Hmmm.... I am a bit confused. :)

If we have a concrete `DW_TAG_subprogram` with an `abstract_origin` (representing e.g. an `always_inline` function), are we counting it as an inlined function or as a concrete one?

If it is a concrete function, we should rename `InlineFnsToBeProcessed`, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101025