[llvm-dev] [RFC] Moving llvm.dbg.value out of the instruction stream

[Chris Lattner via llvm-dev]

> On Oct 24, 2018, at 1:08 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Wed, Oct 24, 2018 at 12:32 PM Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
> One other random thought: how many of these llvm.dbg.* are directly adjacent to each other?  It would be very simple to extend llvm.dbg.value/declare to be a *list* of declarations.  If many of these are next to each other (or are close enough, e.g. simple casts between them) then you could keep the per-instruction design and get the vast majority of the win.  This would be super incremental.
> 
> Yep, the stat I came up with to quantify that was that 52% of dbg.values come in runs of length 8 or greater for this test case. The "variadic" dbg.value idea is good, and it's come up at past BoFs and socials. I think it captures 90% of the efficiency gains in this proposal,

Makes sense, it would be great if someone could prototype it and see how much it helps in practice.  It seems like it would be a huge (and low hanging!) win.

> but doesn't eliminate the bug class of "-g inserts dbg.values that change -O2 codegen".


Unless you’re planning to change *all* of the debug intrinsics, I don’t think your proposal addresses this either.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/523af49a/attachment.html>