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

Jeremy Morse via llvm-dev llvm-dev at lists.llvm.org
Tue May 11 05:49:52 PDT 2021


Hi Heejin,

On Tue, May 11, 2021 at 7:21 AM Heejin Ahn via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> When doing various transformations, such as moving or cloning, on instructions in the LLVM backend MIR, is there a recommended way to update or move their corresponding DBG_VALUE/DBG_VALUE_LIST instructions?
>
> We WebAssembly devs couldn't find a way two years ago so we created a simple class called WebAssemblyDebugValueManager, but now that LLVM gained DBG_VALUE_LIST instruction (which I came to know only recently), I'm wondering if we are reinventing the wheel. When other targets change/move/clone instructions, what do they usually use to update their corresponding debug value instructions?

Unfortunately there is no overall strategy -- the debug intrinsics
need to be kept in the same position (or at least the same order), and
their operands kept referring to a {v,}reg containing the correct
value. Optimisations like machine-copy-propagate and machine-sink have
their own custom code to track debug intrinsics and update them
appropriately, which sometimes is a lot of work. I'm not familiar with
WebAssembly, but as it moves instructions around and re-writes
registers, it too will need to have its own custom tracking code.

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.

Shameless plug: there will be a new way of tracking variable locations
[0] that requires less maintenance in optimisations, and I'm now able
to make progress on it again. It's not completely clear that
WebAssembly would receive all the benefits though, as I understand it
there is no register allocation for WebAssembly.

[0] https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html

--
Thanks,
Jeremy


More information about the llvm-dev mailing list