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

[Reid Kleckner via llvm-dev]

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>