OCHyams wrote:

Thanks for taking a look!

> A summary of DWARF file size/section size changes (how much change as a % of 
> total file size in object and linked executables, as a % of aggregate DWARF 
> section sizes in object and linked executables, and as a % of the specific 
> DWARF section sizes (eg: {.rela,}.debug_line changes by x%) - with specific 
> debug info flags (my preference would be for -fno-standalone-debug -gz=zstd 
> with crel, but I understand if that's not your deployment target, etc, it's 
> less relevant)) 

Here's bloaty figures for some CTMark builds (`$ bloaty <-gkey-instructions> -- 
<-gno-key-instructions>`)

I'm only including `.debug_line` as bloaty reports changes to a few other 
sections of <= 5 bytes in the first table and <= 50 bytes in the second, which 
is negligible.

`-O2 -g -gkey-instructions` vs baseline of `-O2 -g`:

| executable       | .debug_line delta | file size delta |
|------------------|-------------------|-----------------|
| 7zip-benchmark   | +2.4% +15.3Ki     | +0.3% +15.3Ki   |
| bullet           | +0.4% +1.60Ki     | +0.0% +1.61Ki   |
| clamscan         | +2.4% +7.02Ki     | +0.3% +7.03Ki   |
| consumer-typeset | +12% +16.1Ki      | +1.2% +16.1Ki   |
| kc               | +2.4% +6.28Ki     | +0.1% +6.29Ki   |
| lencod           | +1.5% +4.64Ki     | +0.2% +4.65Ki   |
| pairlocalalign   | +1.9% +3.92Ki     | +0.3% +3.93Ki   |
| SPASS            | +1.2% +5.11Ki     | +0.2% +5.12Ki   |
| sqlite3          | +1.6% +4.75Ki     | +0.2% +4.76Ki   |
| tramp3d-v4       | +1.1% +5.43Ki     | +0.1% +5.43Ki   |


`-fno-standalone-debug -gz=zstd -O2 -g -gkey-instructions` vs baseline of 
`-fno-standalone-debug -gz=zstd -O2 -g`:

| executable       | .debug_line delta | file size delta |
|------------------|-------------------|-----------------|
| 7zip-benchmark   | +0.5% +1.20Ki     | +0.0% +1.27Ki   |
| bullet           | +0.4%    +832     | +0.0%    +792   |
| clamscan         | +1.5% +2.36Ki     | +0.2% +2.34Ki   |
| consumer-typeset | +5.4% +4.32Ki     | +0.5% +4.32Ki   |
| kc               | +1.7% +1.55Ki     | +0.1% +1.60Ki   |
| lencod           | +0.9% +1.38Ki     | +0.1% +1.40Ki   |
| pairlocalalign   | +0.4%    +352     | +0.0%    +376   |
| SPASS            | +0.7% +1.23Ki     | +0.1% +1.23Ki   |
| sqlite3          | +0.9% +1.40Ki     | +0.1% +1.43Ki   |
| tramp3d-v4       | +1.0%    +864     | +0.0%    +832   |

There's a compile time cost to enabling the feature ([0.52% on 
compile-time-tracker](http://llvm-compile-time-tracker.com/compare.php?from=8b068149547cb3043e4427899851dc70ca1eb885&to=984de46013b14bec9c3759ef47a853940306ceca&stat=instructions%3Au))
 which was included in the compile-time-cost tables in [this 
post](https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668/20?u=ochyams)
 which explains where we put work in to "pay for" the cost of the feature (and 
we have longer term general improvements we'd like to make).

I'm happy to get more numbers if there're any other configurations you'd like 
to see.


> and which debuggers are effected in what ways (some discussion of gdb would 
> be nice). If this has a cost and no benefit for lldb, seems like maybe we'd 
> want to keep it off under lldb tuning. If it has a cost and no benefit to gdb 
> - then I'd probably say off-by-default, on-for-SCE.

SCE (full disclosure - most tested) and GDB (*) and both work with the feature 
(both provide the promised improved optimisied-code stepping), but LLDB doesn't 
yet. I'd still like to gently suggest we enable it for LLDB too for uniformity, 
especially as we've tried to pay some of the costs in other areas, so the net 
"feature doesn't exist" -> "feature on by default" cost is < 0.3% increased 
`instructions:u` on compile-tim-tracker (and from the other bits of work, max 
rss has come down by 0.87%), unless that seems unreasonable or generally 
undesirable.

(*) Checked with 15.0.50 and 12.0.90. GCC's `-gstatement-frontiers` option 
(which is also enabled by default for optimisations) requires the same debugger 
support as key-instructions and the earliest mention I could find was gcc-8.1 
(2018) https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Debugging-Options.html - I 
would assume (but have not verified) that gdb versions from around then would 
support gcc's `-gstatement-frontiers` and therefore key instructions.


https://github.com/llvm/llvm-project/pull/149509
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to