<div dir="ltr"><div dir="ltr">Hello Jeremy,<div><br></div><div>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?</div><div><br></div><div>Some more questions are inline below:</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 11, 2021 at 5:50 AM Jeremy Morse <<a href="mailto:jeremy.morse.llvm@gmail.com" target="_blank">jeremy.morse.llvm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Heejin,<br>
<br>
On Tue, May 11, 2021 at 7:21 AM Heejin Ahn via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> 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?<br>
><br>
> 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?<br>
<br>
Unfortunately there is no overall strategy -- the debug intrinsics<br>
need to be kept in the same position (or at least the same order), and<br>
their operands kept referring to a {v,}reg containing the correct<br>
value. Optimisations like machine-copy-propagate and machine-sink have<br>
their own custom code to track debug intrinsics and update them<br>
appropriately, which sometimes is a lot of work. I'm not familiar with<br>
WebAssembly, but as it moves instructions around and re-writes<br>
registers, it too will need to have its own custom tracking code.<br>
<br>
Doing this for multiple registers in DBG_VALUE_LIST is much harder. If<br>
it's too difficult, then it's safe to drop the DBG_VALUE_LIST by<br>
making it's register operands $noreg. That should turn into "optimised<br>
out" when seen by a debugger.<br></blockquote><div><br></div><div>Can this also be achieved as just deleting the DBG_VALUE_LIST instruction, or is this going to lose even more info?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Shameless plug: there will be a new way of tracking variable locations<br>
[0] that requires less maintenance in optimisations, and I'm now able<br>
to make progress on it again. It's not completely clear that<br>
WebAssembly would receive all the benefits though, as I understand it<br>
there is no register allocation for WebAssembly.<br>
<br>
[0] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html</a></blockquote><div><br></div><div>Thanks for the pointer! I'll look forward to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
--<br>
Thanks,<br>
Jeremy<br>
</blockquote></div></div>