/ go Public
cmd/compile: pass pointer-shaped receivers using context register #44827
Issues related to the Go compiler and/or runtime.
Feedback is required from experts, contributors, and/or the community before a change can be made.
TL;DR: We should look into passing pointer-shaped receivers using the context register.
Today, receiver parameters are effectively simply prepended to the parameter list. This was convenient when Go only had method expressions (i.e., expressions like
Tis a type), because the same function code could be used for both method calls and method expressions.
However, Go later added method values (i.e., expressions like
xis a value), which require generating wrapper functions and also requires rather complex trampoline code within package reflect. This complexity is needed to adapt between the function closure calling convention (which passes the closure pointer using a dedicated context register) and the method calling convention (which passes receivers using a regular parameter).
If we change the internal calling convention so that receiver arguments are passed using the context register too, then we'd be able to avoid generating method value wrappers. We'd instead need just a single simple, universal wrapper, which could be used by both the compiler and package reflect. (For methods with non-pointer-shaped receivers, we would wrap the interface-calling-convention wrapper for the method, which always uses a pointer-shaped receiver parameter.)
Another benefit (pointed out by @dr2chase) is this would free up an extra register for passing arguments to pointer-receiver methods.
The only downside I see at the moment is that method expressions for pointer-shaped receiver types (e.g.,
(*T).M) would now need compiler-generated wrappers instead. However, the mitigating factors here are: (1) method expressions can only appear in source so we can always statically generate them (unlike for method values); (2) method expressions seem much less commonly used than method values (caveat: based on my anecdotal experience); and (3) it would be easy to reuse wrappers for methods with the same GC shape.
/cc @aclements @dr2chase @mknyszek
The text was updated successfully, but these errors were encountered: