<div dir="ltr">Hello Jeremy,<div><br></div><div>Thank you very much for your answers!</div><div><br></div><div>Regards,</div><div>Heejin</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 12:13 PM Jeremy Morse <<a href="mailto:jeremy.morse.llvm@gmail.com">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,<br>
<br>
On Wed, May 12, 2021 at 4:48 AM Heejin Ahn <<a href="mailto:aheejin@gmail.com" target="_blank">aheejin@gmail.com</a>> wrote:<br>
> 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?<br>
<br>
Not at the moment, and as we're aiming to enhance more passes to emit<br>
DBG_VALUE_LISTs it probably wouldn't last long. There's a better fix<br>
(see below),<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>
><br>
> Can this also be achieved as just deleting the DBG_VALUE_LIST instruction, or is this going to lose even more info?<br>
<br>
Unfortunately deleting isn't safe. Instead, it's safe to replace any<br>
DBG_VALUE_LIST you see with "DBG_VALUE $noreg". This indicates that<br>
there _was_ a variable assignment here, but its value could not be<br>
recovered. Taking that approach won't harm variable location coverage<br>
at all: all the DBG_VALUE_LISTs produced would have been "DBG_VALUE<br>
$noreg" in the past.<br>
<br>
--<br>
Thanks,<br>
Jeremy<br>
</blockquote></div>