<div dir="ltr"><div dir="ltr">On Mon, Oct 12, 2020 at 9:13 AM Cazalet-Hyams, Orlando <<a href="mailto:orlando.hyams@sony.com" target="_blank">orlando.hyams@sony.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div>
<p class="MsoNormal"><span>The "static allocas are special" [3] approach is appealing because it seems like it may give promising results without too much work (compared with these other ideas, anyway). It does rely on passes
 to provide debug-info correctness, but tooling may be an appropriate stand in for correctness by default if we decide to go down this route. Did you have anything in mind for this?</span></p></div></div></blockquote><div><br></div><div>All I had in mind was something like:</div><div>- add a pass that finds all "local variable stores" (stores to a static alloca used by a dbg.declare), and inserts markers (llvm.donothing?) carrying the local variable metadata after every such store</div><div>- after optimization, check that every marker is preceded by either a store to a local variable of a dbg.value for the same local variable. Any marker with no dbg.value or store before it is a bug, unless the variable is available nowhere (I forget how that is represented)</div></div></div>