[PATCH] D116821: [DebugInfo][InstrRef] Move instr-ref controlling flag out of TargetOptions

Mon Jan 24 03:25:55 PST 2022

jmorse added a comment.

I agree with @dblaikie that a bit more time for @alexfh's numbers would be good -- I'd be especially interested in the code characteristics (i.e.: is this a large C++ codebase under LTO, with things like exceptions?). If there are any runs where the build completes, a comparison of how much debug-info is in the before/after files would be great, if that's possible.

> @jmorse - do you have some numbers to help clarify what sort of regressions you were anticipating this patch causing?

For compile time on large C++ codebases, something in the order of 1% regression as the clang frontend took up the vast majority of compile time; on smaller benchmarks, pretty much in line with what CTMark on the compile-time tracker was reporting. I think with the patches from @nikic (cheers!), D117877 <https://reviews.llvm.org/D117877> and something else I've got cooking then the regression on CTMark should be 2-3%. Caroline kindly ran some tests too [0], unfortunately one of the algorithms changed a lot between now and then :/,

For memory consumption, I only observed negligible changes in max-rss when testing C++ codebases, CTMarks numbers for max-rss are roughly 1%. My general expectation is that the instr-ref LiveDebugValues implementation shouldn't be responsible for peak memory usage as it only fully analyses one variable at a time, instead any greater memory usage Should (TM) come from storing the location information for all variables before DWARF emissions happens. If that holds, any increase in max-rss should be somewhat proportionate to a change in the output file size / output debug-info. I can see a few outcomes here:

- Optimistic: the increase in memory usage is in proportion with more debug-info being produced. Discussion should then move to whether we should generate all that data,
- Pessimistic: there's little change in how much debug-info is produced, but lots of extra memory used. That's almost certainly a bug or design problem, to be reverted and investigated,
- Complete misery: I'm aware of a few pathological scenarios that LLVM can't cope with, usually extremely large functions with lots of inlining, where describing all variables locations at the same time simply won't fit in memory. In the past that's been "fixed" by truncating the debug-info for such functions [1]. If that kind of scenario is occurring it's revert-and-write-more-code.

[0] https://lists.llvm.org/pipermail/llvm-dev/2021-September/152457.html
[1] https://reviews.llvm.org/D80662

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116821