<div dir="ltr">You were suggesting that the nice thing about the former was that the user couldn't fail to have a debug location:<br><br><span style="color:rgb(33,33,33)">"The primary benefit of having the API on Instruction is that we can make it impossible to accidentally create a locationless call instruction in a function with debuginfo (which would crash/assert the backend when creating inline scopes)."<br></span><br>Which I'm a bit fuzzy on - if a new call instruction is created it'd still have no location so I'm not sure this choice of API provides extra defense against that mistake.<br><br>If, today, an existing call instruction is moved then the location zero'd out - it's going to need work to replace the zeroing with merging no matter whether the API for that merging is on DebugLoc or Instruction.<br><br>So I guess coming back to your point: could you explain in more detail how having the API on Instruction provides a stronger guarantee/safety than having it elsewhere? I'm not clear on what that's defending against.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 23, 2017 at 9:09 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"><br class="gmail_msg">
> On Feb 22, 2017, at 4:34 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> If an instruction is hoisted across a BB without adjusting the location, a sample based profile taken at that location would incorrectly count a hit to the source BB even though it may not be executed. (eg: CSE moves similar code from an 'if' and 'else' block to before the predecessor (or sinks it to a successor) and picks the 'if' block's instructions as the ones to move (deleting the 'else' block) - now every time the profile observes the evaluation of the common subexpression it counts it as the 'if' block executing - when it's possible the 'if' block never executes and only the 'else' block is ever chosen)<br class="gmail_msg">
<br class="gmail_msg">
That part makes sense to me, my question was more how this would affect our choice between:<br class="gmail_msg">
<br class="gmail_msg">
  Instruction::mergeLocationWith(DebugLoc Other);<br class="gmail_msg">
  Instruction::setMergedLocation(DebugLoc A, DebugLoc B);<br class="gmail_msg">
<br class="gmail_msg">
and<br class="gmail_msg">
<br class="gmail_msg">
  static DebugLoc::getMergedLocation(DebugLoc A, DebugLocB);<br class="gmail_msg">
<br class="gmail_msg">
?<br class="gmail_msg">
<br class="gmail_msg">
-- adrian<br class="gmail_msg">
</blockquote></div>