[PATCH] D68620: DebugInfo: Use base address selection entries for debug_loc

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D68620#2271269 <https://reviews.llvm.org/D68620#2271269>, @probinson wrote:

> In D68620#2266531 <https://reviews.llvm.org/D68620#2266531>, @dblaikie wrote:
>
>> @probinson - do you have any state here? Whether this is an ongoing issue, whether the improvements to avoid unnecessary debug_loc have reduced the overhead sufficiently, etc?
>
> @Orlando mentioned he was collecting some size data that would be relevant here, he'll post it when he's done.  Basically .debug_loc sizes at various points.

Awesome!

> But naively, pre-v5, base-address entries can only make lists longer, and for short lists the size cost is big while the reduction in relocations is small.

Yep, at least on ELF, the relocation is 3 times the size (and uncompressible) than the address itself. So a debug_loc (or debug_range) entry with only a single entry is in favor of base address selection for object file size even without compression (2 addresses + 2 relocations (2 + 2 * 3 == 8), compared to 1 base address selection thing + 1 address + 1 relocation + 2 offsets == 7), but yes, that doubles the address size in the linked binary.

> I'd have to agree with @wolfgangp that the space-time tradeoff probably is not favorable for small lists,

My hope/wonder is whether the reduction in unnecessary small (single entry that has scope identical to the enclosing scope: ie: the variable doesn't need a location list - it should use a direct location instead) entries might help make the tradeoff less problematic.

> and maybe there should be some threshold.  I know that's more complicated on the emission side, but it's not a trivial thing in the final object.  Orlando showed me a preliminary chart where .debug_loc went from ~30% of all debug info in LLVM 5.0 to ~50% in LLVM 10.0, in one of our benchmarks.

Yeah - not sure exactly what basis to use to choose that threshold as it'll depend on how important object file size versus binary size is, whether you're using compression (whether only compressing DWARF in objects, executables, or both). But also making it a customizable number doesn't seem super helpful either. Open to ideas, for sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68620