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: Missed opportunity for post-inlining devirtualization #38992
Comments
I guess there's really two pieces here: |
Inlining in the compiler happens far before devirtualization. Changing that is difficult, unfortunately. Missed optimization opportunities due to compiler ordering problems are among the most difficult to address. |
Yes agreed. You basically end up needing to run some variant of passes 2x. I can imagine an architecture which tries to minimize costs looking something like:
Someone will inevitably be back a month after this and ask you to run devirtualization again after the second inlining, because unless you just run the whole optimizer stack again and again until you reach a fixed point, you'll always miss something, but this approach seems tractable and like it probably balances compiler performance with emitted code performance. |
It is unfortunately far more complicated than that. The internal representation in the compiler changes dramatically between those passes. You can’t just run a second “mini-inlining” pass later. I’d like to move inlining later in the compiler in general, but that’s a major undertaking and raises a number of thorny issues. |
Oof, yes, different IRs would significantly complicate this. I'll refrain from further speculation, since while I was a compiler engineer in a former life, I don't know gc's internals at all. |
Well, if you feel inspired to learn, we’re happy to help you find your way around. More hands are always welcome. :) |
For additional context, this issue was extracted from a search for a less code-duplicative way to implement the patch which became xitongsys/parquet-go#258 |
In my closed duplicate thread, I have proposed changes in |
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
)?amd64/linux
What did you do?
When compiling the following code, there are missed opportunities for devirtualization: https://go.godbolt.org/z/7tPdJK
What did you expect to see?
I expected that
in32FuncTable.MinMax
contains no indirect calls:Min
/Max
are inlined, and recursivelyCmp
is devirtualized and inlined.What did you see instead?
Virtual calls to
Cmp
are emitted inint32FuncTable_MinMax_pc0
:The text was updated successfully, but these errors were encountered: