[PATCH] D142556: [DebugInfo] Merge partially matching chains of inlined locations

David Stenberg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 3 06:53:05 PST 2023


dstenb added a comment.

In D142556#4086340 <https://reviews.llvm.org/D142556#4086340>, @dblaikie wrote:

> In D142556#4085390 <https://reviews.llvm.org/D142556#4085390>, @dstenb wrote:
>
>> In D142556#4080303 <https://reviews.llvm.org/D142556#4080303>, @dblaikie wrote:
>>
>>> Oh, neat idea - but I wonder what it does to the DIE tree, rather than just the line table? Do we end up with 3 inlined_subroutines? (one for each of the original calls, if tehy have any unique instructions after inlining, then one for this sythesized call? I guess that's not strictly worse - the instructions were from some sort of inlining... )
>>
>> Yes, we will end up with 3 inlined_subroutines in the example above (as both original calls have unique instructions):
>
> How's the performance?

Sorry, I have been blocked by other work. I have now measure compilation speed for an opt 8.0 binary with the RelWithDebInfo build type using patched respectively unpatched versions of trunk (those were Release builds).

This was done a shared machine, so the load varied a bit over time, but I've built opt 40 times with respective binary and these are the user time results:

  # With patch
  [67.32661666666667, 67.33988333333333, 68.00153333333333, 69.95165, 70.0251, 70.08698333333332, 70.10561666666666, 70.15785000000001, 70.1597, 70.16915, 70.1803, 70.22085, 70.2247, 70.30366666666666, 70.30761666666666, 70.31343333333334, 70.31875, 70.43641666666667, 70.5036, 70.50515, 70.51246666666667, 70.53808333333333, 70.57755, 70.60194999999999, 70.64415000000001, 70.84625, 71.6538, 73.79506666666667, 73.89473333333333, 74.56911666666666, 76.15891666666667, 76.41226666666667, 79.76478333333333, 81.38295, 81.68751666666667, 86.29401666666666, 87.57535, 89.4209, 95.79031666666667, 109.24031666666667]
  mean: 74.44997666666667
  median: 70.50880833333333
  std: 8.485396943096646
  
  # Without patch
  [66.41356666666667, 67.65480000000001, 70.14276666666667, 70.14448333333334, 70.18646666666667, 70.19085, 70.2014, 70.21263333333333, 70.26146666666666, 70.26425, 70.26745, 70.28258333333333, 70.28881666666666, 70.36748333333333, 70.41218333333335, 70.44623333333334, 70.47338333333333, 70.48428333333334, 70.51248333333334, 70.51689999999999, 70.54706666666667, 70.55458333333333, 70.55946666666667, 70.57926666666667, 70.58081666666666, 70.70003333333334, 70.99738333333333, 71.0452, 71.10905, 72.0509, 77.86593333333333, 79.43435000000001, 79.80055, 84.38, 88.10063333333333, 97.71156666666667, 98.03155, 101.29769999999999, 106.61161666666666, 115.31475]
  mean: 75.92492250000001
  median: 70.53198333333333
  std: 11.548023516184701

So, it seems that this patch is not affecting the compile time noticeably, at least for this normal case.


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

https://reviews.llvm.org/D142556



More information about the llvm-commits mailing list