From #568:

I try to explain what I've thought to understand and what I think should be the UI for that.

• "real" inline (the compiler is free to inline or not after all) means that the compiler includes the code for a function within another function
• the actual generation (and therefore the diassembly) may be different in each place concerning the context (for example a compiler may recognize that specific parts can only be taken in specific cases and remove the other parts)
• perf should trace the execution of that as it is tracing non-inlined code

Running objdump shows the disassembly for the "outer" function, therefore the inlined code is part of the disassembly, possibly multiple times (= we can "see" the specific generation for this specific place).
Code-wise we see a function call.

If we can deduce the place of that disassembly to be part of the "calling" place (where it is inlined) then we can directly attribute the costs there.

If we can't do it, then we still have the "original" place (source reference and/or function name) and on the other hand we have the costs in the function of "calling" it (this is something that can be seen in the caller/callee tab, also with this PR applied).
Ideally we'd then be able to attribute the "summed" costs for the disassembly to the calling place -but I do recognize that in this case we'd have to match that in the code, which is not possible to always get correct because of the preprocessor work (for example macros) - we shouldn't start that path.

This leaves the question: Is there a way to deduce the "calling" source reference for functions that are inlined? If we yes, then we should attribute the total costs to that place.