-
Notifications
You must be signed in to change notification settings - Fork 13.4k
clang-13 performs inlining after mcount instrumentation #52853
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
This is because we invoke (It's vacation time so probably won't get around to fixing this soon) |
At least for the post-inline case, wouldn't it be better undo that part of the change, and move this back into the backend pipeline? Having a pass that needs to be inserted into the post-link LTO pipeline by the frontend seems problematic, as the frontend may not control the LTO pipeline if linker plugin LTO rather than compiler LTO is used. |
…pelines (#92171) Move EntryExitInstrumenter(PostInlining=true) to as late as possible and EntryExitInstrumenter(PostInlining=false) to an early pre-inlining stage (but skip for ThinLTO post-link). This should fix the issues reported in rust-lang/rust#92109 and #52853. These are caused by https://reviews.llvm.org/D97608.
is this fixed now? #92171 is merged and it documents that it tries to fix this issue |
I did not test it, but chances are it is fixed. |
In clang-13 inlining might follow the mcount instrumentation used by -pg.
The mcount relies on frame pointers to recover a call graph, so inlining after
inserting calls to mcount produces misleading end results. In the example
below, g which is called only once is recorded as being called 1025 times:
This seems to be result of changes from https://reviews.llvm.org/D97608,
which moved PostInlineEntryExitInstrumentationPass out of TargetPassConfig::addIRPasses.
cc @aeubanks
The text was updated successfully, but these errors were encountered: