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

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In D68620#2276034 <https://reviews.llvm.org/D68620#2276034>, @Orlando wrote:

>> (as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))
>
> I'm not sure, I'll defer to @probinson on that.

What we actually care about is turnaround time, which for debug info encompasses compile time, link time, debugger startup time, and the attendant I/O latencies.  Note that console download time is *not* a factor, as our downloader knows to omit the debug info.

It's not exactly raw size that matters, but we ought to care how efficiently the information is encoded in the file data.  So, with respect to location/range lists, multiplying the number of entries without reducing the number of relocations is bad all around.  The compiler has to produce more data; the linker has to copy more data, without any compensating reduction in relocation processing time; the debugger has to read more data to get the same information content.

Do we know how often a location/range list has a single non-base-address entry?  Clearly we can avoid a list at all if the location/range aligns with the containing scope (the ValidThroughout case); single-entry lists would come up where that range is a subset of the containing scope, but still only needs one entry.  In those cases, there's no object-file or final-binary benefit to having a base-address entry followed by a single list entry.  And that optimization really wouldn't have to be under a flag, because it would always be a win, even in v5.
Apologies for not going to look myself...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68620