[PATCH] Fixing line numbers of inlined allocas

[Adrian Prantl]

>>! In D5401#8, @dblaikie wrote:
> 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).

It isn't. No DebugLoc means reuse the location of the previous insn, or, if there was no previous insn, it means we are in the function prologue. Line 0 on the other hand is actually emitted in the line table and carries the special meaning: this is compiler-generated code with no source that could be associated with it. LLDB, for instance, treats line 0 as "always skip over this, the developer would never want to stop here". Clang uses this for ObjC retain/release calls inserted by the compiler, for instance.
> 
> & 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.

http://reviews.llvm.org/D5401