[PATCH] D96045: [llvm-dwarfdump][locstats] Unify handling of inlined vars with no loc
Djordje Todorovic via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 13 00:30:24 PDT 2021
djtodoro added a comment.
In D96045#2684570 <https://reviews.llvm.org/D96045#2684570>, @dblaikie wrote:
> In D96045#2678117 <https://reviews.llvm.org/D96045#2678117>, @rdhindsa wrote:
>
>> After moving the variable InlinedFnsToBeProcessed to inside the for loop, I noticed a difference in two dwarfdump statistics for a quite large binary with fission=yes:
>>
>> #variables processed by location statistics
>> #variables with 0% of parent scope covered by DW_AT_location
>>
>> Since I am not very familiar with this code, I would request if you could investigate and apply the patch.
>
> Hmm, looking at this trying to reproduce the behavior makes me think this wouldn't be the right fix & the change in numbers is probably reflective of a bug in the fix - specifically in LTO situations (where the abstract origin of the function may be in a different CU than the one it's referenced from/inlined into).
>
> But there might be a reasonable alternative fix/improvement - pruning the contents of the list once it has been handled. Possibly sorting the list so it's easy to just visit the elements that need to.
I have taken a look into this and come up with the similar conclusion.
This could be reproduced with the Split DWARF -- when building e.g. GDB project with -gsplit-dwarf option enabled, it triggers the issue. I was struggling to make a simple test case (from a high level) that meets all the requirements, but it is very hard. That is why I've sent the email: https://lists.llvm.org/pipermail/llvm-dev/2021-April/149735.html.
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