<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 12:32 PM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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.</div></div></div></blockquote><div><br></div><div>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, but doesn't eliminate the bug class of "-g inserts dbg.values that change -O2 codegen".</div></div></div>