[PATCH] Fixing line numbers of inlined allocas

[David Blaikie]

So currently if you have an instruction with no DebugLoc that's inlined
into a function with debug info, that instruction appears to get the
DebugLoc of the call site, yes? (if I'm understanding this correctly)

We could, maybe, ish, fix this by describing the instruction as inlined -
but our DebugLoc schema doesn't really have a way to describe "no specific
location, but it's inlined within this scope" (line/col 0, but with a
scope, maybe? Is line/col 0 the same as no DebugLoc? I guess it probably
is, but I'm not sure).

& what this patch is proposing is to special case static allocas with no
DebugLoc and assign them the same DebugLoc as other static allocas? (what
if there aren't any?) which should be the null DebugLoc. I suspect the more
general solution than this is to just ensure that instructions with no
DebugLoc continue to have no DebugLoc when they're inlined (they certainly
shouldn't end up with the call sites DebugLoc - without inlining info, etc).

But, yes, potentially from a source fidelity perspective we could see if a
0 line/col(/file) DebugLoc with scoping information  could be used to
produce reasonable output, and then special case the prologue handling code
to be a bit smarter about instructions with DebugLocs... but I don't know
how smart that would end up being.

On Wed, Oct 15, 2014 at 9:54 AM, Adrian Prantl <aprantl at apple.com> wrote:

> Wouldn't it be a better fix to use the proper location for the alloca and
> rather fix the backend to follow the inlinedAt references in the alloca's
> debug location when deciding the end of the prologue?
>
> http://reviews.llvm.org/D5401
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141015/d7df4100/attachment.html>