[PATCH] D27462: For functions with debug info, do not propagate the callsite debug location to inlined instructions.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 6 11:47:07 PST 2016


On Tue, Dec 6, 2016 at 11:29 AM Paul Robinson via Phabricator <
reviews at reviews.llvm.org> wrote:

> probinson added inline comments.
>
>
> ================
> Comment at: lib/Transforms/Utils/InlineFunction.cpp:1377-1378
>        if (!DL) {
> +        if (CalleeHasDebugInfo)
> +          continue;
>          // If the inlined instruction has no line number, make it look as
> if it
> ----------------
> dblaikie wrote:
> > Leaving this instruction without a location at all may be problematic -
> it's still certainly inlined from this other function... - what can we do
> about that, if anything? (only thing that comes to mind is giving it a zero
> debug location, but that doesn't sound right)
> >
> > Maybe no debug location is the right solution... - I wonder how that
> interacts with the inline range for the instruction, etc.
> If it had no location in the called function, seems like it's not
> inherently different for it to have no location when moved into the calling
> function.  An instruction with no location implicitly inherits the
> preceding location, no? That's no different in the caller than the callee.
>

Well, ish. The specifically interesting part would be if the inlined code
gets spread around, or any instructions at the start of the inlined code.

say we have a function with instructions:

A
B(loc1)

inlined into function with instructions:

C(loc2)
D(call, loc3)

so we end up with:

C(loc2)
A
B(loc1->loc3)

So now the range of the inlined function is {B}, whereas it really should
be {A, B}, even if A gets no specific location (essentially the ideal would
be A gets an inherited location from the prior instruction, except if that
crosses the inlined function boundary)

But that's probably impractical to implement in LLVM quickly/easily, so
this is probably a reasonable fix for now.

Adrian - thoughts?


>
>
> https://reviews.llvm.org/D27462
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161206/98adc4b7/attachment.html>


More information about the llvm-commits mailing list