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

[via llvm-dev]

The variadic llvm.dbg.value idea would basically eliminate the compile-time-performance motivation to solve it the right way.  But if those same lists would ultimately be attached to real instructions, or labels, it's a step in the right direction.
(I've been grousing about debug-info instructions for years. llvm.dbg.declare can be eliminated by adding one parameter to alloca. It's lovely to see someone who understands IR way better than I do, trying to solve this.)
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev
Sent: Thursday, October 25, 2018 12:43 AM
To: Reid Kleckner
Cc: llvm-dev
Subject: Re: [llvm-dev] [RFC] Moving llvm.dbg.value out of the instruction stream




On Oct 24, 2018, at 1:08 PM, Reid Kleckner <rnk at google.com<mailto: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/20181025/14a187ce/attachment.html>