[llvm-dev] [RFC] Moving llvm.dbg.value out of the instruction stream (original) (raw)

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 23 10:07:48 PDT 2018

On Tue, Oct 23, 2018 at 9:40 AM Adrian Prantl <aprantl at apple.com> wrote:

At first glance, this example seems to contradict the definition in the Design section. If a !dbgvalue describes the debug info before the instruction, I would have expected the syntax to be like

%v1 = call i32 @foo(), !dbg !1 %v2 = call i32 @foo(), !dbg !2, !dbgvalue i32 %v1, variable !123, loc !456 [, expr ...] So my question is: which instruction is the !dbgvalue attached to, and should we make this more explicit in the syntax?

Well, the syntax was meant to show that the value tracking starts immediately before the instruction it is attached to. It's an internal implementation whether we attach the tracking to the instruction before or after the location where the variable assignment appears, the label will appear in between them. I think, for internal implementation reasons, it's best to attach the value tracking to the next instruction after the value appears, so the dbg value notionally happens before the instruction its attached to. This makes sense because every block has at least one terminator, even if it is just unreachable.

On Tue, Oct 23, 2018 at 9:53 AM Adrian Prantl <aprantl at apple.com> wrote:

[resending with a bugfix s/x/y/ in my example]

We still have to support constant dbg.values that need to be at a specific point in the instruction stream and don't refer to any SSA value. For example, we can still have code like this:

Yes, for exactly this reason, I don't want to attach dbgvalue tracking info to the instructions that produce the values. I tried to list that as an explicit non-goal. We always have to be able to handle the general case of the variable being assigned a value far from the location where it is computed.

The main idea in this proposal is just to make BB ilists more dense to make optimization more efficient, and as noted at the end of the RFC, if it's just efficiency we're after, it may not be the top priority. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181023/a8df10cc/attachment.html>

More information about the llvm-dev mailing list