[llvm-dev] Notes from dbg.value coffee chat

[Reid Kleckner via llvm-dev]

On Fri, Oct 9, 2020 at 9:38 AM Cazalet-Hyams, Orlando <
orlando.hyams at sony.com> wrote:

> Hi Reid,
>
>
>
> Thanks for sharing this. I plan to work on improving debug-info for
> variables
>
> living in memory as my next "project" so I am very interested to hear with
> what
>
> others have to say about "Idea 1".
>
>
>
> There is one part of the idea that confuses me. You say we could "keep the
>
> dbg.declare instructions", but I don't see where dbg.declare instructions
> - at
>
> least with their current semantics - fit into the design if the frontend is
>
> emitting dbg.values after every assignment. Could you please expand on
> this part
> a little?
>

I think what I meant is that we need to keep the association between the
alloca and the local variable somewhere. The current implementation of
dbg.declare is not what we want: when we have one, it overrides any
dbg.values, and the alloca is used as the variable location for the full
scope. That's not what we want, but we do need an association between
alloca and variable+scope somewhere. The dbg.values in the design as we
discussed it would not contain the alloca, but the SSA value which is
stored to the alloca. Maybe if we augmented the dbg.values with the store
destination, we could get by without tracking that information separately.

The main design goal here was to have the variable location information be
correct even when DSE occurs, without updating every pass that deletes
stores, because there are many. Thinking about it today, I'm not sure this
design is complete yet. Even if the frontend effectively emits two stores
for every assignment, a real store, and dbg.value, the backend needs to
determine if the real store survived optimization. If it did, then the
variable value lives in memory. If it did not, then the variable value is
the value which would've been stored, if it is available at this program
point, or if it is available somewhere nearby. Maybe that's acceptable, but
it seems difficult. However, maybe that's similar to what we already do for
dbg.values uses that precede definitions.

The alternative to this design would be to say that stores to static
allocas are special, and cannot be deleted without updating debug info.
This is basically https://llvm.org/pr34136#c25. Thinking about it again
today, maybe this approach is feasible. We could build tooling to audit for
passes that delete these special "assigning stores". Maybe that's better
than bending over backwards just to make it easy for the optimizers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201009/0ef50f73/attachment.html>