[PATCH] D72797: [llvm-dwarfdump][Statistics] Distinguish functions/variables with same name across different CUs

[Kristina Bessonova via Phabricator via llvm-commits]

krisb added a comment.

@aprantl @djtodoro thanks for the comments!

I updated the description adding more clear and reproducible testing results for 'O0' build.
There is no 100% of availability even on non-optimized build because of 2 issues:

- some variables really don't have locations. They are usually artificial or global variables, but the number of them is really small (for example, 46/1435958 for clang-34 binary).
- parameters may have different `DW_AT_decl_file` and `DW_AT_decl_line` among instances of the same function. It looks like this happens when a function has its declaration and definition in different header files. So, one can find something like this in dwarf (these are two concrete out-of-line instances of the same 'foo' function).

  DW_TAG_subprogram
    DW_AT_name  ("foo")
    DW_AT_decl_file ("definition.h")
    DW_AT_decl_line (222)
    DW_TAG_formal_parameter
      DW_AT_name  ("__a")
      DW_AT_decl_file ("declaration.h")
      DW_AT_decl_line (370)
    DW_TAG_formal_parameter
      DW_AT_name  ("__b")
      DW_AT_decl_file ("declaration.h")
      DW_AT_decl_line (370)
  
  DW_TAG_subprogram
    DW_AT_name  ("foo")
    DW_AT_decl_file ("definition.h")
    DW_AT_decl_line (222)
    DW_TAG_formal_parameter
      DW_AT_name  ("__a")
      DW_AT_decl_file ("definition.h")
      DW_AT_decl_line (222)
    DW_TAG_formal_parameter
      DW_AT_name  ("__b")
      DW_AT_decl_file ("definition.h")
      DW_AT_decl_line (222)

So, this increases number of 'total vars' because these '__a' and '__b' variables counted twice.

I also was a bit optimistic about how this patch(es) affects the performance of the statistics, it actually became two times slower than before the patches.



================
Comment at: llvm/tools/llvm-dwarfdump/Statistics.cpp:393
         return;
+      // Skip weird functions w/o names.
+      if (StringRef(Die.getName(DINameKind::LinkageName)).empty())
----------------
aprantl wrote:
> When are these generated? Could we write something more descriptive into the comment?
I haven't had a chance to debug such cases properly, but I believe they are a result of some bugs in dwarf generation flow.
Such functions have no attributes at all but can contain some children (usually structures or classes). So, I removed the check by now cause it's better to fix the issue in dwarf generation than workaround it in statistics.   


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72797