Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attribute inline cost to caller #586

Open
lievenhey opened this issue Jan 8, 2024 · 3 comments
Open

Attribute inline cost to caller #586

lievenhey opened this issue Jan 8, 2024 · 3 comments

Comments

@lievenhey
Copy link
Contributor

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.

@milianw
Copy link
Member

milianw commented Jan 10, 2024

I would need a clear example code base with actual and expected data. I fail to understand this purely on this description I'm afraid

@lievenhey
Copy link
Contributor Author

Here is the rest of the conversation:
grafik

@GitMensch
Copy link
Contributor

Here's a bit more information in pictures:

the callee view shows (likely correct) costs of inline functions:
grafik
as we found, there is no guaranteed single place for inlined functions, so "Disassemble" is not active

the location view shows the cost per location, like
grafik

We therefore can deduce from the caller/callee tab, that:

  • most cost is in this inline function
  • most cost is in line 418

We can open the disassembly of the function we looked at (here: inspect_common) and see on the disassembly view the disassembly for the inlined function at the right place (which sadly does not contain any costs with the current appimage, I think it did so earlier) and in the source view we can recognize that the line with that high cost is exactly the inlined function
grafik
(we may have deduced that from their identical numbers)

This FR is mainly about having the inlined function costs (here 22.8) assigned as "cycles incl".
Providing the detailed costs in the disassembly (again?) would be very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants