[llvm-dev] [RFC] DebugInfo: A different way of specifying variable locations post-isel

[Jeremy Morse via llvm-dev]

Hi Vedant,

On Wed, Feb 26, 2020 at 6:49 PM Vedant Kumar <vedant_kumar at apple.com> wrote:
> >> Do you expect that handling for the current and new-style DBG_VALUEs could coexist in LiveDebugValues? Could that be done by e.g. introducing a new debug instr MI (DBG_INSTR_REF)?
> >
> > I believe it should be relatively straightforwards: we would have an
> > additional kind of location-record (i.e. VarLoc) that, instead of
> > identifying a _variable_, identified the instruction/operand that
> > computed a value. Handling a DBG_INSTR_REF as you suggest would mean
> > looking up such a VarLoc by instruction/operand to find its register,
> > then creating a register location VarLoc for the variable as we do
> > today. Propagating the location of an instruction/operand VarLoc would
> > happen in exactly the same way as variable locations today, it's just
> > following a value as it's moved around registers.
>
> I see, so the required addition to LiveDebugValues is basically about reconstituting VarLocs from new-style debug values? And otherwise, the basic range extension algorithm is unchanged?

Correct -- the dataflow analysis shouldn't require any kind of
algorithmic change, instead we're altering the position at which
values get tracked to be specified by a defining instruction, rather
than a DBG_VALUE. We're also adding two different flavours of
location:
 * Values that are not yet variable locations
 * Variable locations that don't yet have their value defined (use-before-def)
However I don't believe these two new flavours alter the algorithm,
they're just making different use of the information it produces. (96%
certain).

> <stitching together a response to a sub-thread with Adrian>
>
> >> What about constants and memory locations?
> >
> > Good question, and something I've not done too much thinking about. As
> > far as I'm aware, memory references today are all register based, with
> > the DIExpression expressing any memory operations. That should
> > translate to the proposed model naturally: memory locations would be
> > instruction references with a suitable DIExpression qualifying the
> > value.
>
> For stack slots, I guess we'd mostly still rely on the MachineFunction side-table.
>
> We do sometimes refer to stack locations using a register-based description, like:
>
>   DBG_VALUE $rsp, 0, ![[SVAR]], !DIExpression(DW_OP_constu, 8, DW_OP_minus, DW_OP_plus_uconst, 1)
>
> Under the proposed new model, we could change this to a DBG_INSTR_REF pointing to the instruction which creates the memory location. I think this is how it's done in IR. An alternative might be to have the DBG_INSTR_REF point to the instruction that completes the store of the variable into the memory location. That doesn't sound as good to me. It doesn't seem like it'd be simple to work out the location from the instruction (e.g. if we're storing into an offset).

Hmmmm, this raises some interesting extra questions -- for example, I
don't believe there are instructions creating memory locations until
the PrologEpilog pass runs. An easy solution would be just to retain
DBG_VALUEs referring to frame-indexs, but that replicates some of the
flaws in referring to registers (multiple defs), although not to the
same extent. Offsets from the stack pointer aren't determined until
PrologEpilog too. Slightly more design work is probably needed here.

~

Reid wrote:
> Basically, I think this is a great idea.

Much appreciated!,

> Debug values effectively represent the original program location of an assignment (or PHI, but let's ignore that for now) and the assigned value. Transforms should focus on preserving information about the assigned value, not the original program location of the assignment. Transforms should already know how to calculate the assigned value in terms of other values, but they shouldn't have to know anything about variable assignments, control dependence, etc.

Strong agree; the more of this we can design out of maintaining
variable location information the better.

~

Seeing how feedback has been positive, I'll hack up a prototype
sometime soon to allow for experimentation. I think one of the bigger
risks in the whole idea is having all variable locations hinge on
LiveDebugValues' ability to track values: if there's some loss of
information about instructions by the time we reach LiveDebugValues,
it might be impossible to track or guarantee many variable locations.
We would also be increasing the number of locations that it has to
follow (through the new flavours of VarLocs); I'm not too concerned
about this, as I don't believe there would be many more locations than
we track today.

--
Thanks,
Jeremy