<div dir="ltr">This was my concrete example from the PR (<a href="https://llvm.org/bugs/show_bug.cgi?id=31891">https://llvm.org/bugs/show_bug.cgi?id=31891</a>):<div><pre class="gmail-bz_comment_text" id="gmail-comment_text_0" style="white-space:pre-wrap;width:50em;color:rgb(0,0,0)">void useit1(float);
void useit2(float);
double fabs(double);
float fabsf(float f) {
  return (float)fabs((double)f);
}
void hoistit(int cond, float f) {
  if (cond) {
    useit1(fabsf(f));
  } else {
    useit2(fabsf(f));
  }
}</pre>Obviously, hoisting the common call to fabsf is profitable. What line information should we assign to it, both for profiling and for line table purposes?</div><div><br></div><div>Stripping the location info or saying "line 0" is equivalent to saying "hoistit line 0", because we'll add a line table entry for the prologue, as David says. The alternative is to arbitrarily choose one of the others, leading to a potentially confusing backtrace or profile. For the debugging use case, this just seems like a cost of doing business with an optimized binary, but for PGO, it creates a bad profile.</div><div><br></div><div>I think the proposed solution of stripping the line info but leaving scope info on the call is probably the right thing to do for now. It handles all use cases that we have today. Eventually I like Adrian's idea of a bit on the DILocation or Instruction that says "sloc info consumer beware: this instruction was hoisted or speculated". That preserves the most information. The one use case I can think of for that bit it is sanitizer instrumentation, where any source location is better than no source location (want file, function, and approximate line), and grovelling around in the nearby instruction stream isn't easy.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 9:25 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So Reid came across a case where the current strategy (dropping locations when they move across basic blocks) proves to be at odds with another precept we have: inlinable calls must have locations, so that if/when they are inlined the location can be accurately described (due to the nature of our IR representation of inlining, a location must be given for the call site so that the DIEs for the inlined subroutine can be described)<br><br>Any ideas on how we should approach this?<br><br>We could have a bit in DebugLoc (or other choice of representation) for the non-line location. For the line table this would work the same as absent DebugLoc - for calls it would cause call_file/line/discriminator (do we have a call_discriminator? We probably should, don't know if we do) to be omitted which is something the LLVM IR representation currently can't express.<br></div>
</blockquote></div><br></div>