Add total function byte size and inline function byte size to "llvm-dwarfdump --statistics"

[clayborg]

Summary

A nice metric to know is how much code you have in debug info (in bytes) versus the the number of bytes for inlined functions. This patch reports the total number of bytes for concrete functions (size of all DW_TAG_subprogram DIE address ranges), and the total number of bytes for top level inlined functions. This can help users know how much code has been inlined and help users tune for code size.

The formatted JSON output looks like:

{
  "version":1,
  "file":"/tmp/a.out.dSYM/Contents/Resources/DWARF/a.out",
  "format":"Mach-O 64-bit x86-64",
  "source functions":4,
  "inlined functions":6,
  "unique source variables":8,
  "source variables":10,
  "variables with location":10,
  "call site entries":0,
  "scope bytes total":789,
  "scope bytes covered":789,
  "total function size":147,
  "total inlined function size":39
}

The last two keys "total function size" and "total inlined function size" are new.

[aprantl]

Thanks. There seems to be some overlap with

[llvm-dev] RFC: Adding a code size analysis tool
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html

how was that discussion resolved?

[vsk]

In D54217#1290474, @aprantl wrote:

Thanks. There seems to be some overlap with

[llvm-dev] RFC: Adding a code size analysis tool
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html

how was that discussion resolved?

I think the response was generally positive but I haven't had the time to push things into tree. @clayborg, have you tried out the tool here: https://github.com/vedantk/llvm-project ? The RFC has some usage instructions.

If you just want the ratio of inlined to not-inlined bytes, this patch is a simpler way to do it. But if you need something more fine-grained (i.e. *which* functions were inlined more compared to a baseline, by how much, etc.), it might be worth checking out. Happy to have someone else run with the code.

[clayborg]

In D54217#1290504, @vsk wrote:

In D54217#1290474, @aprantl wrote:

Thanks. There seems to be some overlap with

[llvm-dev] RFC: Adding a code size analysis tool
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html

how was that discussion resolved?

I think the response was generally positive but I haven't had the time to push things into tree. @clayborg, have you tried out the tool here: https://github.com/vedantk/llvm-project ? The RFC has some usage instructions.

If you just want the ratio of inlined to not-inlined bytes, this patch is a simpler way to do it. But if you need something more fine-grained (i.e. *which* functions were inlined more compared to a baseline, by how much, etc.), it might be worth checking out. Happy to have someone else run with the code.

This current patch is indeed for an overview of inlined to not-inlined bytes. I have other patches to --statistics that will display more output coming. Breaking down exact sizes of inlined functions by count and size will be part of this future output. But this current one is just for a quick breakdown. Like you said in the URL provided, it is nice to know that say 30% of your code is inlined. If you are expecting less inlining and try a new option, this can be a quick way to see results in a very concise kind of way.

[vsk]

In D54217#1290630, @clayborg wrote:

In D54217#1290504, @vsk wrote:

In D54217#1290474, @aprantl wrote:

Thanks. There seems to be some overlap with

[llvm-dev] RFC: Adding a code size analysis tool
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html

how was that discussion resolved?

I think the response was generally positive but I haven't had the time to push things into tree. @clayborg, have you tried out the tool here: https://github.com/vedantk/llvm-project ? The RFC has some usage instructions.

If you just want the ratio of inlined to not-inlined bytes, this patch is a simpler way to do it. But if you need something more fine-grained (i.e. *which* functions were inlined more compared to a baseline, by how much, etc.), it might be worth checking out. Happy to have someone else run with the code.

This current patch is indeed for an overview of inlined to not-inlined bytes. I have other patches to --statistics that will display more output coming. Breaking down exact sizes of inlined functions by count and size will be part of this future output. But this current one is just for a quick breakdown. Like you said in the URL provided, it is nice to know that say 30% of your code is inlined. If you are expecting less inlining and try a new option, this can be a quick way to see results in a very concise kind of way.

Sure, I have no objections. As you're thinking about future patches, though, I'd just suggest that you take a look at what can be salvaged/shared from my size tool prototype. There's some neat stuff there, like displaying full inlining trees. There's also an option to treat a batch of dSYMs as one unit, so you can compare all of the dsyms from one build of an OS to another, and see which symbols grew the most, were inlined the most, etc. If that's out of scope for what you need, that's fine too.

[clayborg]

In D54217#1290632, @vsk wrote:

In D54217#1290630, @clayborg wrote:

In D54217#1290504, @vsk wrote:

In D54217#1290474, @aprantl wrote:

Thanks. There seems to be some overlap with

[llvm-dev] RFC: Adding a code size analysis tool
https://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html

how was that discussion resolved?

I think the response was generally positive but I haven't had the time to push things into tree. @clayborg, have you tried out the tool here: https://github.com/vedantk/llvm-project ? The RFC has some usage instructions.

If you just want the ratio of inlined to not-inlined bytes, this patch is a simpler way to do it. But if you need something more fine-grained (i.e. *which* functions were inlined more compared to a baseline, by how much, etc.), it might be worth checking out. Happy to have someone else run with the code.

This current patch is indeed for an overview of inlined to not-inlined bytes. I have other patches to --statistics that will display more output coming. Breaking down exact sizes of inlined functions by count and size will be part of this future output. But this current one is just for a quick breakdown. Like you said in the URL provided, it is nice to know that say 30% of your code is inlined. If you are expecting less inlining and try a new option, this can be a quick way to see results in a very concise kind of way.

Sure, I have no objections. As you're thinking about future patches, though, I'd just suggest that you take a look at what can be salvaged/shared from my size tool prototype. There's some neat stuff there, like displaying full inlining trees. There's also an option to treat a batch of dSYMs as one unit, so you can compare all of the dsyms from one build of an OS to another, and see which symbols grew the most, were inlined the most, etc. If that's out of scope for what you need, that's fine too.

I will definitely take a look when I get to that point!

[clayborg]

So sounds like we are ok with the idea of this patch. Any comments on the patch itself?

[vsk]

Looks reasonable to me, but it'd help to check in a .o for a test.

[clayborg]

In D54217#1291170, @vsk wrote:

Looks reasonable to me, but it'd help to check in a .o for a test.

There don't seem to be any tests for any of this. Are there existing tests for stuff that is only in llvm-dwarfdump? If so, please point me to where they are.

[dblaikie]

In D54217#1291793, @clayborg wrote:

In D54217#1291170, @vsk wrote:

Looks reasonable to me, but it'd help to check in a .o for a test.

There don't seem to be any tests for any of this. Are there existing tests for stuff that is only in llvm-dwarfdump? If so, please point me to where they are.

Where/how did you look for tests? I know they're not perfectly organized, but my usual approach is to search for some existing text nearby (in this case I searched the github for 'scope bytes covered' the statistic just before the ones you added - and I found this test case: https://github.com/llvm-mirror/llvm/blob/9d809925c655ce689c4a99025c180f15ac8a7a53/test/tools/llvm-dwarfdump/X86/statistics.ll ) or to look at the revision history of the feature I'm adding to & see what the last functional change was there, and if/how it was tested.

[clayborg]

yeah, an easy code search indeed kicked up the tests. I will add one. Sorry about that

[clayborg]

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

[probinson]

In D54217#1291828, @clayborg wrote:

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

In the bin directory of your build, there should be llvm-lit.py; run that, passing the relative filespec of the test file (full filespec probably works too but I never use it that way). This will give you a pass/fail on the one test file. Add -v to get detailed output if it fails.

[dblaikie]

In D54217#1291820, @clayborg wrote:

yeah, an easy code search indeed kicked up the tests. I will add one. Sorry about that

No worries - still curious where you were looking for the tests initially, perhaps we can do something to make them more discoverable?

(another way I find tests: Break something nearby/related (eg: remove one of the existing statistics) & see what tests fail)

In D54217#1291828, @clayborg wrote:

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

from the build directory I usually run "./bin/llvm-lit -v test/tools/llvm-dwarfdump/X86/statistics.ll" for example (yeah, even though that relative path doesn't exist in the build directory, lit knows to also try resolving it from the source dir, etc)

[clayborg]

In D54217#1291834, @dblaikie wrote:

In D54217#1291820, @clayborg wrote:

yeah, an easy code search indeed kicked up the tests. I will add one. Sorry about that

No worries - still curious where you were looking for the tests initially, perhaps we can do something to make them more discoverable?

The only thing I could think of that could make it easier is to make a symlink from the tools/llvm-dwarfdump/test which points to ../../test/tools/llvm-dwarfdump

(another way I find tests: Break something nearby/related (eg: remove one of the existing statistics) & see what tests fail)

In D54217#1291828, @clayborg wrote:

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

from the build directory I usually run "./bin/llvm-lit -v test/tools/llvm-dwarfdump/X86/statistics.ll" for example (yeah, even though that relative path doesn't exist in the build directory, lit knows to also try resolving it from the source dir, etc)

Thanks! Will be an easy tests to add. One other FileCheck question. Seems like I would want to check that "total function size" and "total inlined function size" exist. Can I rely on the exact byte sizes from this .ll file on all systems? I guess I don't really care what the value is, but I would like to verify that "total function size" > "total inlined function size". Is there a way to do that?

CHECK: "total function size":[[FUNCSIZE:[0-9]+]]
CHECK: "total inlined function size":[[INLINESIZE:[0-9]+]]

Is there a way to check FUNCSIZE > INLINESIZE?

[dblaikie]

In D54217#1291854, @clayborg wrote:

In D54217#1291834, @dblaikie wrote:

In D54217#1291820, @clayborg wrote:

yeah, an easy code search indeed kicked up the tests. I will add one. Sorry about that

No worries - still curious where you were looking for the tests initially, perhaps we can do something to make them more discoverable?

The only thing I could think of that could make it easier is to make a symlink from the tools/llvm-dwarfdump/test which points to ../../test/tools/llvm-dwarfdump

Ah, fair enough - yeah, might just be a hurdle we can live with, then. The tests mostly match the directory hierarchy - but yeah, there are a few quirks.

(another way I find tests: Break something nearby/related (eg: remove one of the existing statistics) & see what tests fail)

In D54217#1291828, @clayborg wrote:

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

from the build directory I usually run "./bin/llvm-lit -v test/tools/llvm-dwarfdump/X86/statistics.ll" for example (yeah, even though that relative path doesn't exist in the build directory, lit knows to also try resolving it from the source dir, etc)

Thanks! Will be an easy tests to add. One other FileCheck question. Seems like I would want to check that "total function size" and "total inlined function size" exist.
Can I rely on the exact byte sizes from this .ll file on all systems?

Only if the test has a specific triple. Which, by the looks of it, this test could benefit from. @aprantl - would that make sense? This test is only run when the X86 target is enabled anyway, so adding a specific triple wouldn't make it less portable - and would allow for specific statistic values to be tested, which seems like it'd be important for test coverage here (as it stands, byte count parts of this test look like it would still pass even if the statistics were miscomputed/all zero, etc).

I guess I don't really care what the value is, but I would like to verify that "total function size" > "total inlined function size". Is there a way to do that?

CHECK: "total function size":[[FUNCSIZE:[0-9]+]]
CHECK: "total inlined function size":[[INLINESIZE:[0-9]+]]

Is there a way to check FUNCSIZE > INLINESIZE?

Yeah, there's no way to do that, unfortunately - but I think (will wait for Adrian to weigh in here, as the original author/has more context for this test/features than I do) it'd make sense to put a specific triple on this test and test specific values for all the stats here.
If adding new features to test to this test case perturbs all the other statistics in a way that makes this test a pain to maintain (I doubt it will - probably cheap enough to change the test, eyeball all the new stat values, and just update these "golden" values when we have to) it may be better to split new features that would otherwise perturb things into new test files.

[clayborg]

Added to the lit tests to ensure the function size and inline function sizes are present

[vsk]

This looks good to me. I think it'd help to have a +1 from Adrian, as he's worked on this file much more than I have.

[dblaikie]

In D54217#1291870, @dblaikie wrote:

In D54217#1291854, @clayborg wrote:

In D54217#1291834, @dblaikie wrote:

In D54217#1291820, @clayborg wrote:

yeah, an easy code search indeed kicked up the tests. I will add one. Sorry about that

No worries - still curious where you were looking for the tests initially, perhaps we can do something to make them more discoverable?

The only thing I could think of that could make it easier is to make a symlink from the tools/llvm-dwarfdump/test which points to ../../test/tools/llvm-dwarfdump

Ah, fair enough - yeah, might just be a hurdle we can live with, then. The tests mostly match the directory hierarchy - but yeah, there are a few quirks.

(another way I find tests: Break something nearby/related (eg: remove one of the existing statistics) & see what tests fail)

In D54217#1291828, @clayborg wrote:

Looks like I can piggy back on llvm/test/tools/llvm-dwarfdump/X86/statistics.ll

Does anyone know how to run only this test from command line?

from the build directory I usually run "./bin/llvm-lit -v test/tools/llvm-dwarfdump/X86/statistics.ll" for example (yeah, even though that relative path doesn't exist in the build directory, lit knows to also try resolving it from the source dir, etc)

Thanks! Will be an easy tests to add. One other FileCheck question. Seems like I would want to check that "total function size" and "total inlined function size" exist.
Can I rely on the exact byte sizes from this .ll file on all systems?

Only if the test has a specific triple. Which, by the looks of it, this test could benefit from. @aprantl - would that make sense? This test is only run when the X86 target is enabled anyway, so adding a specific triple wouldn't make it less portable - and would allow for specific statistic values to be tested, which seems like it'd be important for test coverage here (as it stands, byte count parts of this test look like it would still pass even if the statistics were miscomputed/all zero, etc).

@aprantl - any thoughts on the test coverage here. Currently there's no testing that these counters are correct/meaningful - just that they are printed out. Reckon it's worth putting a specific triple here & testing the values to ensure the computation is correct/doesn't regress?

[aprantl]

I'm afraid that any numbers won't be really stable — especially the ones about code size. In fact, we are getting a notifications whenever any of those values regresses via LNT (http://lnt.llvm.org/db_default/v4/nts/114748), so that kind of covers the values of the statistics?
For other parameters (number of non-inlined functions), it may be more obvious that expecting a hard-coded value is the right thing.

[vsk]

Why not check in a .o? The numbers won't change, so they can meaningfully be compared.

[dblaikie]

In D54217#1292323, @vsk wrote:

Why not check in a .o? The numbers won't change, so they can meaningfully be compared.

An object file or assembly seems fine, yeah.

[dblaikie]

In D54217#1292327, @dblaikie wrote:

In D54217#1292323, @vsk wrote:

Why not check in a .o? The numbers won't change, so they can meaningfully be compared.

An object file or assembly seems fine, yeah.

I should say - I know this can be a bit more of a pain to maintain - modifications to the test case usually involve rerunning the compiler, etc. (though the same is true for LLVM IR debug info metadata usually - we don't generally hand-craft it) - and I wouldn't be averse to an IR test case that was stabilized - there are ways to pretty thoroughly restrict the compiler's ability to optimize anything too far (using function calls (to functions declared but not defined), inline assembly, etc).

But yeah, assembly or object files are probably the right tool here - very few (& I probably would've pushed back on this one going in in the first place if I'd noticed) test case for dwarfdump use IR, the rest use object files or assembly.

llvm/trunk/test/tools/llvm-dwarfdump/X86/statistics.ll

 ; -1 square::i
 ; CHECK: "variables with location":7
 ; CHECK: "scope bytes total":[[BYTES:[0-9]+]]
 ; Because of the dbg.value in the middle of the function, the pc range coverage
 ; must be below 100%.
 ; CHECK-NOT: "scope bytes covered":0
 ; CHECK-NOT "scope bytes covered":[[BYTES]]
 ; CHECK: "scope bytes covered":
+; CHECK: "total function size":[[FUNCSIZE:[0-9]+]]
+; CHECK: "total inlined function size":[[INLINESIZE:[0-9]+]]
+
 
 ; ModuleID = '/tmp/quality.cpp'
 source_filename = "/tmp/quality.cpp"
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.12.0"
 
 %struct.S = type { i8 }
 

llvm/trunk/tools/llvm-dwarfdump/Statistics.cpp

struct PerFunctionStats {
   /// Number of constants with location across all inlined instances.
   unsigned ConstantMembers = 0;
   /// List of all Variables in this function.
   StringSet<> VarsInFunction;
   /// Compile units also cover a PC range, but have this flag set to false.
   bool IsFunction = false;
 };
 
-/// Holds accumulated global statistics about local variables.
+/// Holds accumulated global statistics about DIEs.
 struct GlobalStats {
   /// Total number of PC range bytes covered by DW_AT_locations.
   unsigned ScopeBytesCovered = 0;
   /// Total number of PC range bytes in each variable's enclosing scope,
   /// starting from the first definition of the variable.
   unsigned ScopeBytesFromFirstDefinition = 0;
   /// Total number of call site entries (DW_TAG_call_site).
   unsigned CallSiteEntries = 0;
+  /// Total byte size of concrete functions. This byte size includes
+  /// inline functions contained in the concrete functions.
+  uint64_t FunctionSize = 0;
+  /// Total byte size of inlined functions. This is the total number of bytes
+  /// for the top inline functions within concrete functions. This can help
+  /// tune the inline settings when compiling to match user expectations.
+  uint64_t InlineFunctionSize = 0;
 };
 
 /// Extract the low pc from a Die.
 static uint64_t getLowPC(DWARFDie Die) {
   auto RangesOrError = Die.getAddressRanges();
   DWARFAddressRangesVector Ranges;
   if (RangesOrError)
     Ranges = RangesOrError.get();
   else
     llvm::consumeError(RangesOrError.takeError());
   if (Ranges.size())
     return Ranges[0].LowPC;
   return dwarf::toAddress(Die.find(dwarf::DW_AT_low_pc), 0);
 }
 
 /// Collect debug info quality metrics for one DIE.
 static void collectStatsForDie(DWARFDie Die, std::string FnPrefix,
                                std::string VarPrefix, uint64_t ScopeLowPC,
                                uint64_t BytesInScope,
+                               uint32_t InlineDepth,
                                StringMap<PerFunctionStats> &FnStatMap,
                                GlobalStats &GlobalStats) {
   bool HasLoc = false;
   uint64_t BytesCovered = 0;
   uint64_t OffsetToFirstDefinition = 0;
 
   if (Die.getTag() == dwarf::DW_TAG_call_site) {
     GlobalStats.CallSiteEntries++;
if (BytesInScope) {
     FnStats.ConstantMembers++;
   }
 }
 
 /// Recursively collect debug info quality metrics.
 static void collectStatsRecursive(DWARFDie Die, std::string FnPrefix,
                                   std::string VarPrefix, uint64_t ScopeLowPC,
                                   uint64_t BytesInScope,
+                                  uint32_t InlineDepth,
                                   StringMap<PerFunctionStats> &FnStatMap,
                                   GlobalStats &GlobalStats) {
   // Handle any kind of lexical scope.
-  if (Die.getTag() == dwarf::DW_TAG_subprogram ||
-      Die.getTag() == dwarf::DW_TAG_inlined_subroutine ||
-      Die.getTag() == dwarf::DW_TAG_lexical_block) {
+  const dwarf::Tag Tag = Die.getTag();
+  const bool IsFunction = Tag == dwarf::DW_TAG_subprogram;
+  const bool IsBlock = Tag == dwarf::DW_TAG_lexical_block;
+  const bool IsInlinedFunction = Tag == dwarf::DW_TAG_inlined_subroutine;
+  if (IsFunction || IsInlinedFunction || IsBlock) {
 
     // Reset VarPrefix when entering a new function.
     if (Die.getTag() == dwarf::DW_TAG_subprogram ||
         Die.getTag() == dwarf::DW_TAG_inlined_subroutine)
       VarPrefix = "v";
-  
     // Ignore forward declarations.
     if (Die.find(dwarf::DW_AT_declaration))
       return;
 
     // Count the function.
-    if (Die.getTag() != dwarf::DW_TAG_lexical_block) {
+    if (!IsBlock) {
       StringRef Name = Die.getName(DINameKind::LinkageName);
       if (Name.empty())
         Name = Die.getName(DINameKind::ShortName);
       FnPrefix = Name;
       // Skip over abstract origins.
       if (Die.find(dwarf::DW_AT_inline))
         return;
       // We've seen an (inlined) instance of this function.
       auto &FnStats = FnStatMap[Name];
       FnStats.NumFnInlined++;
       FnStats.IsFunction = true;
     }
 
     // PC Ranges.
     auto RangesOrError = Die.getAddressRanges();
     if (!RangesOrError) {
       llvm::consumeError(RangesOrError.takeError());
       return;
     }
-       
     auto Ranges = RangesOrError.get();
     uint64_t BytesInThisScope = 0;
     for (auto Range : Ranges)
       BytesInThisScope += Range.HighPC - Range.LowPC;
     ScopeLowPC = getLowPC(Die);
 
-    if (BytesInThisScope)
+    if (BytesInThisScope) {
       BytesInScope = BytesInThisScope;
+      if (IsFunction)
+        GlobalStats.FunctionSize += BytesInThisScope;
+      else if (IsInlinedFunction && InlineDepth == 0)
+        GlobalStats.InlineFunctionSize += BytesInThisScope;
+    }
   } else {
     // Not a scope, visit the Die itself. It could be a variable.
     collectStatsForDie(Die, FnPrefix, VarPrefix, ScopeLowPC, BytesInScope,
-                       FnStatMap, GlobalStats);
+                       InlineDepth, FnStatMap, GlobalStats);
   }
 
+  // Set InlineDepth correctly for child recursion
+  if (IsFunction)
+    InlineDepth = 0;
+  else if (IsInlinedFunction)
+    ++InlineDepth;
+
   // Traverse children.
   unsigned LexicalBlockIndex = 0;
   DWARFDie Child = Die.getFirstChild();
   while (Child) {
     std::string ChildVarPrefix = VarPrefix;
     if (Child.getTag() == dwarf::DW_TAG_lexical_block)
       ChildVarPrefix += toHex(LexicalBlockIndex++) + '.';
 
     collectStatsRecursive(Child, FnPrefix, ChildVarPrefix, ScopeLowPC,
-                          BytesInScope, FnStatMap, GlobalStats);
+                          BytesInScope, InlineDepth, FnStatMap, GlobalStats);
     Child = Child.getSibling();
   }
 }
 
 /// Print machine-readable output.
 /// The machine-readable format is single-line JSON output.
 /// \{
 static void printDatum(raw_ostream &OS, const char *Key, StringRef Value) {

 /// compilers is.
 bool collectStatsForObjectFile(ObjectFile &Obj, DWARFContext &DICtx,
                                Twine Filename, raw_ostream &OS) {
   StringRef FormatName = Obj.getFileFormatName();
   GlobalStats GlobalStats;
   StringMap<PerFunctionStats> Statistics;
   for (const auto &CU : static_cast<DWARFContext *>(&DICtx)->compile_units())
     if (DWARFDie CUDie = CU->getUnitDIE(false))
-      collectStatsRecursive(CUDie, "/", "g", 0, 0, Statistics, GlobalStats);
+      collectStatsRecursive(CUDie, "/", "g", 0, 0, 0, Statistics, GlobalStats);
 
   /// The version number should be increased every time the algorithm is changed
   /// (including bug fixes). New metrics may be added without increasing the
   /// version.
   unsigned Version = 1;
   unsigned VarTotal = 0;
   unsigned VarUnique = 0;
   unsigned VarWithLoc = 0;
bool collectStatsForObjectFile(ObjectFile &Obj, DWARFContext &DICtx,
   printDatum(OS, "inlined functions", NumInlinedFunctions);
   printDatum(OS, "unique source variables", VarUnique);
   printDatum(OS, "source variables", VarTotal);
   printDatum(OS, "variables with location", VarWithLoc);
   printDatum(OS, "call site entries", GlobalStats.CallSiteEntries);
   printDatum(OS, "scope bytes total",
              GlobalStats.ScopeBytesFromFirstDefinition);
   printDatum(OS, "scope bytes covered", GlobalStats.ScopeBytesCovered);
+  printDatum(OS, "total function size", GlobalStats.FunctionSize);
+  printDatum(OS, "total inlined function size", GlobalStats.InlineFunctionSize);
   OS << "}\n";
   LLVM_DEBUG(
       llvm::dbgs() << "Total Availability: "
                    << (int)std::round((VarWithLoc * 100.0) / VarTotal) << "%\n";
       llvm::dbgs() << "PC Ranges covered: "
                    << (int)std::round((GlobalStats.ScopeBytesCovered * 100.0) /
                                       GlobalStats.ScopeBytesFromFirstDefinition)
                    << "%\n");
   return true;
 }