<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div dir="ltr">On Tue, Oct 23, 2018 at 9:40 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At first glance, this example seems to contradict the definition in the Design section. If a !dbgvalue describes the debug info *before* the instruction, I would have expected the syntax to be like<br><br>  %v1 = call i32 @foo(), !dbg !1<br>  %v2 = call i32 @foo(), !dbg !2, !dbgvalue i32 %v1, variable !123, loc !456 [, expr ...]<br><br>So my question is: which instruction is the !dbgvalue attached to, and should we make this more explicit in the syntax?</blockquote></div><div dir="ltr"><br></div><div>Well, the syntax was meant to show that the value tracking starts immediately before the instruction it is attached to. It's an internal implementation whether we attach the tracking to the instruction before or after the location where the variable assignment appears, the label will appear in between them. I think, for internal implementation reasons, it's best to attach the value tracking to the next instruction after the value appears, so the dbg value notionally happens before the instruction its attached to. This makes sense because every block has at least one terminator, even if it is just `unreachable`.</div><div dir="ltr"><br></div><div dir="ltr">On Tue, Oct 23, 2018 at 9:53 AM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span style="font-family:Menlo-Regular">[resending with a bugfix s/x/y/ in my example]</span></div><span style="font-family:Menlo-Regular"><div><span style="font-family:Menlo-Regular"><br></span></div>We still have to support constant dbg.values that need to be at a specific point in the instruction stream and don't refer to any SSA value.</span><br style="font-family:Menlo-Regular"><span style="font-family:Menlo-Regular">For example, we can still have code like this:</span></div></blockquote><div><br></div><div>Yes, for exactly this reason, I *don't* want to attach dbgvalue tracking info to the instructions that produce the values. I tried to list that as an explicit non-goal. We always have to be able to handle the general case of the variable being assigned a value far from the location where it is computed.</div><div><br></div><div>The main idea in this proposal is just to make BB ilists more dense to make optimization more efficient, and as noted at the end of the RFC, if it's just efficiency we're after, it may not be the top priority.</div></div></div>