-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
cmd/compile/internal/devirtualize: PGO devirtualization lost when inlining function containing devirtualized call #62245
Comments
I can reproduce this as well, thanks.
|
I suppose this is a fundamental mismatch between the way PGO devirtualization works and the way inlining works with unified IR. PGO devirtualization edits the function IR to replace interface calls with a conditional direct or indirect call based on a type assertion. This runs prior to inlining so that the direct call is eligible for inlining. But during inlining, the inlining itself is done with This theoretically impacts any edits to the IR between IR/export data creation and inlining, but as far as I can tell PGO devirtualization is the only such editing. For PGO devirtualization, I'm not sure that there is a good quick fix for this. We could run PGO devirtualization again after inlining (which is also when static devirtualization occurs), but that is only a band-aid: devirtualization that occurs at that point won't get the inlining we desire. I think the best long-term solution would be to combine inlining and devirtualization (static and PGO) into the same pass, so we can iteratively apply both: inlining can enable devirtualization, which can in turn enable more inlining, and so on. This idea is related to #52193. cc @mdempsky |
cc @thanm |
@mdempsky for the immediate term: do you foresee any correctness problems with the current behavior of the primary |
Is it possible to update the "Unified IR export data" after devirtualization? (Perhaps we only need to update inlineable functions, to reduce unnecessary work.) |
That's a good question, I'm not sure how complex that is. Just as a clarification, #62245 (comment) refers to inlining within the same package. I think if inlining occurs across packages it should be OK, since the function body containing PGO devirtualization will get written out to the disk version of the export data. |
Ack, I'm looking into this. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
debug compiler output
go tool objdump -s '^main' pgo
What did you expect to see?
Debug compiler output says
In the objdump of
main.loopVirtual
I expected to see an itab check and conditional direct call (and maybe inlined function body instead of direct method call).What did you see instead?
In the objdump of
main.loopVirtual
I see an unconditional indirect call via DX registerThe text was updated successfully, but these errors were encountered: