[llvm-dev] DBG_VALUE / DBG_VALUE_LIST handling when moving/cloning instructions

[Heejin Ahn via llvm-dev]

Hello Jeremy,

Thank you very much for your answers!

Regards,
Heejin

On Wed, May 12, 2021 at 12:13 PM Jeremy Morse <jeremy.morse.llvm at gmail.com>
wrote:

> Hi,
>
> On Wed, May 12, 2021 at 4:48 AM Heejin Ahn <aheejin at gmail.com> wrote:
> > Thanks for the reply! Given that our DebugValueManager does not handle
> DBG_VALUE_LIST correctly now, is there a way to disable generation of
> DBG_VALUE_LIST instruction or list version of dbg.value.list intrinsic in
> IR?
>
> Not at the moment, and as we're aiming to enhance more passes to emit
> DBG_VALUE_LISTs it probably wouldn't last long. There's a better fix
> (see below),
>
> >> Doing this for multiple registers in DBG_VALUE_LIST is much harder. If
> >> it's too difficult, then it's safe to drop the DBG_VALUE_LIST by
> >> making it's register operands $noreg. That should turn into "optimised
> >> out" when seen by a debugger.
> >
> > Can this also be achieved as just deleting the DBG_VALUE_LIST
> instruction, or is this going to lose even more info?
>
> Unfortunately deleting isn't safe. Instead, it's safe to replace any
> DBG_VALUE_LIST you see with "DBG_VALUE $noreg". This indicates that
> there _was_ a variable assignment here, but its value could not be
> recovered. Taking that approach won't harm variable location coverage
> at all: all the DBG_VALUE_LISTs produced would have been "DBG_VALUE
> $noreg" in the past.
>
> --
> Thanks,
> Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210512/da8c2e89/attachment.html>