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

reflect, cmd/compile: TypeOf(a) == TypeOf(b) doesn't optimize well #65524

Open
dominikh opened this issue Feb 5, 2024 · 0 comments
Open

reflect, cmd/compile: TypeOf(a) == TypeOf(b) doesn't optimize well #65524

dominikh opened this issue Feb 5, 2024 · 0 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@dominikh
Copy link
Member

dominikh commented Feb 5, 2024

reflect.TypeOf(a) == reflect.TypeOf(b) should optimize to a simple comparison of the type pointers stored in the interface value (or in the itab if a and b aren't any)

Currently, the code compiles more naively: it's constructing new interface values with *rtypes stored in them, to then call ifaceeq.

@josharian offered the following analysis on Slack:

poking under the hood a bit, it looks like there are two stumbling blocks to that compiling down nicely:

  • reflect.TypeOf returns nil when passed nil. that introduces a branch into the inlined code that the compiler can't reason its way around.
  • there's a missing optimization. calls to runtime.ifaceeq can be converted to a single pointer equality if the compiler knows that the type is (a) non-nil and (b) a direct iface. which (if you remove point one above), the compiler should be able to know, at least as of ssa time.

note that it's not just enough to know locally that at the callsite that the argument to typeof is non-nil. it has to make it through a few layers:
[...]
the type punning in particular in TypeOf prevents the compiler from doing some optimizations. (i think maybe the optimizations there could be strengthened, but this is danger zone stuff.)
for reference, here is [i]faceeq:
[...]
you can see how for known non-nil types containing pointers (which are "direct"), this whole thing collapses to a pointer equality check.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 5, 2024
@dr2chase dr2chase added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 8, 2024
@mknyszek mknyszek added this to the Unplanned milestone Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
Development

No branches or pull requests

5 participants