<div dir="ltr"><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">Hi llvm-dev,</span><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">I've a few patches up for review that change [0] the
placement of dbg.value intrinsics in optimised code, and Paul has pointed
out that I might be creating a new interpretation of what their location in the
instruction stream _means_. <span style="font-size:11pt">My question for the list would be whether the new interpretation matches current expectations about how dbg.value intrinsics should work, and if not, will this new interpretation conflict significantly with existing code.</span></p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">To illustrate the potential change I've written up an addition to the "Source
Level Debugging" page here [1] describing how I believe these intrinsics
should be interpreted. To summarise, in comparison with
dbg.declares, dbg.values:</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> * Correspond to
assignments in the source program,</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> * Terminate any location specified by dbg.values that appeared earlier in control flow,</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> * Indicate by
their position in the IR where in the instruction stream the change in variable location should occur.</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The docs patch also writes down a debuginfo objective
which I don't believe is documented elsewhere: when recording variable
locations for debuginfo in optimised code, the debugger should never be able to observe a set of variable values that did not appear in the unoptimised
program. (And that it's better for variables to be ``optimised out'' than to
present an inauthentic state of the program).</p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">[0] </span><a href="https://reviews.llvm.org/D58453" style="font-size:11pt;color:rgb(5,99,193)">https://reviews.llvm.org/D58453</a><br></p>

<p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">[1] <a href="https://reviews.llvm.org/D58726" style="color:rgb(5,99,193)">https://reviews.llvm.org/D58726</a></p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">--</p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Thanks,</p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Jeremy</p><p class="gmail-MsoPlainText" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br></p></div>