<div dir="ltr">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></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 22, 2017 at 4:29 PM 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" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 22, 2017, at 4:25 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_-337407346997817082Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Feb 22, 2017 at 4:21 PM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" class="gmail_msg" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">aprantl added a comment.<br class="gmail_msg"><br class="gmail_msg">[apologies for iterating so slowly at the moment]<br class="gmail_msg"><br class="gmail_msg">In<span class="m_-337407346997817082Apple-converted-space gmail_msg"> </span><a href="https://reviews.llvm.org/D29833#682595" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D29833#682595</a>, @twoh wrote:<br class="gmail_msg"><br class="gmail_msg">> Personally I prefer the existing API, because it doesn't allow the transient state before merging. For example, in lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp in this patch, DebugLoc of NewSI is not actually valid after line 1430. Existing API doesn't have this problem.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">If that is the only concern, would an additional convenience function solve (= sufficiently hide) the problem?<br class="gmail_msg"><br class="gmail_msg"> <span class="m_-337407346997817082Apple-converted-space gmail_msg"> </span>Instruction::setMergedDebugLoc(DebugLoc A, DebugLoc B) {<br class="gmail_msg">   <span class="m_-337407346997817082Apple-converted-space gmail_msg"> </span>setDebugLoc(A);<br class="gmail_msg">   <span class="m_-337407346997817082Apple-converted-space gmail_msg"> </span>mergeDebugLocWith(B);<br class="gmail_msg"> <span class="m_-337407346997817082Apple-converted-space gmail_msg"> </span>}<br class="gmail_msg"><br class="gmail_msg">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 class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Either way we have a bug - either the profile will be buggy or the inlining broken, honestly since the buggy profile is harder to diagnose (because it has a location, but an incorrect one) I'd sort of favor an API that makes those bugs easy/the default, rather than the subtlety of incorrect locations.</div></div></div></div></blockquote><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">If we have to make a choice between buggy profile and a broken inline info (that will assert) I agree with you. But can you remind me why the DILocation::getMergedDebugLocation() API prevents the buggy profile?</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- adrian</div></div></blockquote></div>