[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