When a function F is inlined, InlineFunction extends the debug location of every instruction inlined from F by adding an InlinedAt.
However, if an instruction has a 'null' debug location, InlineFunction would propagate the callsite debug location to it. This behavior existed since revision 210459
(http://llvm.org/viewvc/llvm-project?view=revision&revision=210459).
Revision 210459 was originally committed specifically to workaround the lack of debug information for
instructions inlined from intrinsic functions (which are usually declared with attributes __always_inline__, __nodebug__).
The problem with revision 210459 is that it doesn't make any sort of distinction between instructions inlined from a 'nodebug' function and instructions which are inlined from a function built with debug info. When performing PGO on some game code, I noticed that r210459 was the main reason why some instructions in the sample had incorrect counts. As a consequence, a basic block was incorrectly seen as hot, and this was leading to a poor machine block placement.
Note that this issue may also lead to incorrect stepping in the debugger.
My fix works under the assumption that a nodebug function does not have a DISubprogram. When a function F is inlined into another function G, InlineFunction checks if it has debug info associated with it.
For nodebug functions, the InlineFunction logic is unchanged (i.e. it would still propagate the callsite debugloc to the inlined instructions). Otherwise, InlineFunction no longer propagates the callsite debug location.
Please let me know if okay to commit.
Thanks,
Andrea