[PATCH] Fixing line numbers of inlined allocas

[David Blaikie]

>>! In D5401#12, @wolfgangp wrote:
>>>! In D5401#11, @aprantl wrote:
>>>>! In D5401#10, @echristo wrote:
>>>> 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).
>>>> 
>>> 
>>> This is likely the right solution.
>> 
>> Agreed, especially since we want the alloca in this example to be counted towards the prologue.
>> 
>> -- adrian
> 
> Thank you for the input, gentlemen. I'm concerned by the following comment in fixupLineNumbers() in Transforms/Utils/InlineFunction.cpp:
> 
>        // If the inlined instruction has no line number, make it look as if it
>         // originates from the call location. This is important for
>         // ((__always_inline__, __nodebug__)) functions which must use caller
>         // location for all instructions in their function body.
>         BI->setDebugLoc(TheCallDL);

worth being concerned about - I wonder if we could detect that case specifically and special-case it.

I can imagine a few ways - literally checking whether the function we're inlining has the nodebug attribute (does that even persist to IR? Or does the frontend handle it entirely). Checking if the function we're inlining is a known debug info function (might have to build the FunctionDIs to have that around to reference... )... 

What would happen to your test case if we had nodebug on the callee? I guess your solution would still work for that (adjusting the debugloc of the allocas) - maybe we're just going to have to clear the allocas' DebugLocs anyway?

To sum up:

If we special case non-debug functions when inlining, attributing their instructions to the call site, but non-debug instructions in debug functions were just persisted with no debug location then we'd still need to special case allocas from non-debug functions to avoid this bug in that case.

So it sounds like we need to special case the static allocas, but the special case should probably be to not add a debugloc for them (unlike other instructions).

Then there remains an open question as to whether, for debugloc-less instructions in non-nodebug functions, should they be treated the same as instructions in nodebug functions (attributed to the call site) or unattributed? (for now I'm happy to leave them handled the same way as nodebug instructions, attributing them to the call site)

http://reviews.llvm.org/D5401