DW_TAG_subprogram DIEs should not be counted in the inlined function statistic. This also addresses the source variables count, as that uses the inlined function count in its calculations.
Details
Diff Detail
Event Timeline
test/tools/llvm-dwarfdump/X86/statistics.ll | ||
---|---|---|
21 | According to the comment on line 20 "source variables" is expected to be "unique source variables"+"number of extra inlined instances". If we want to change this we should update the comment as well. I'd expect this program to have GlobalConst, Global, constant, s, square::i, cube:i, cube::squared = 7 unique variables, and source variables should be one more than that because it also counts the inlined square::i inside of cube. This obviously isn't documented very well :-(, but based on that do you think this looks more like a bug in the documentation or do you think the algorithm is wrong? |
aprantl@, you were right, my original change was not correctly updating the variable counts to include variables occuring in inlined instances of functions. I have update the patch to fix this issue. There were two additional changes needed: one to make sure we were counting variables for functions that had no inlined instances at all; and one to avoid double-counting member constants.
Now we correctly count only real constant members as "constant members" and we count global variables with locations as part of the "vars with locs".
I would recommend bumping the version number, too, since the results from earlier versions won't be comparable, right?
test/tools/llvm-dwarfdump/X86/stats-inlining-multi-cu.ll | ||
---|---|---|
7 | Seems right. | |
9 | Where do the extra two variables come from? | |
tools/llvm-dwarfdump/Statistics.cpp | ||
139 | That looks definitely correct. |
test/tools/llvm-dwarfdump/X86/stats-inlining-multi-cu.ll | ||
---|---|---|
9 | There are two inlined instances, each of which has 3 variables (parameter T, i from the first lexical block, i from the second lexical block); function a has a local variable 'a'; function b has a local variable 'b'. Total = 8. |
test/tools/llvm-dwarfdump/X86/stats-inlining-multi-cu.ll | ||
---|---|---|
9 | Is this counting the template parameter T as a variable? That seems wrong to me. I think we should only count entities that could have a DW_AT_location in their DW_TAG. |
test/tools/llvm-dwarfdump/X86/stats-inlining-multi-cu.ll | ||
---|---|---|
9 | Pedantically, a DW_TAG_template_value_parameter can have a DW_AT_location, for instance. (but yeah, I agree - a count of variables probably shouldn't include template (type, value or otherwise) parameters) |
I was mistaken before: we were never counting the template parameters. What was happening was that we were counting the variables in both inlined instances, and we were also counting the variables for a concrete, out-of-line instance of the inlined function, even though in this particular case there was no concrete out-of-line instance. I have updated the patch now to only count vars in DW_TAG_subprogram DIEs if the subprogram DIE has PC addresses. I believe this is the correct fix for this issue.
tools/llvm-dwarfdump/Statistics.cpp | ||
---|---|---|
275 | I think we still need the + Constants here or VarTotal can be smaller than VarWithLoc which would be unintuitive. |
It appears to me that on line 131 we are already adding/counting the ConstantMembers in FnStats.VarsInFunction, so adding "+ Constants" would be counting them twice. Alternatively we can change the code on line 131 to not include ConstantMembers...
According to the comment on line 20 "source variables" is expected to be "unique source variables"+"number of extra inlined instances". If we want to change this we should update the comment as well.
I'd expect this program to have GlobalConst, Global, constant, s, square::i, cube:i, cube::squared = 7 unique variables, and source variables should be one more than that because it also counts the inlined square::i inside of cube.
This obviously isn't documented very well :-(, but based on that do you think this looks more like a bug in the documentation or do you think the algorithm is wrong?