Open aclements opened 4 years ago
Change https://golang.org/cl/356519 mentions this issue: cmd/compile/internal: add ABI register information for riscv64
Change https://golang.org/cl/357974 mentions this issue: cmd/compile: change context register from X20 to X26
Change https://golang.org/cl/357976 mentions this issue: runtime,cmd/compile: change duff{zero,copy} register for regabi
Change https://golang.org/cl/359337 mentions this issue: cmd/compile/internal: add ABI register info for riscv64
Should I assume riscv register ABI will not make the 1.18 release? That's what it looks like to me, but I want to confirm before bumping this to 1.19.
@dr2chase yes.
Currently ABIInternal can only be used with assembler functions in the runtime package. Are there any plans to change that in the future so other assembler functions can take advantage of the register ABI?
As the name states, currently ABIInternal is an internal ABI and not a stable one. Therefore it is limited specifically for internal uses. Once we make it (or some revised version of it) a stable ABI, it can be used in assembly code more widely.
(And at that time we'll probably call it ABI1 or something, instead of ABIInternal.)
Currently ABIInternal can only be used with assembler functions in the runtime package. Are there any plans to change that in the future so other assembler functions can take advantage of the register ABI?
I do not think opening ABI1 (when ABIinternal is a stable ABI) to user is a good idea.
The reason is that if ABI1 needs to be improved in the future, in order to consider the compatibility of user assembly code, we may introduce a new ABI, and when it is stable, it will be called ABI2. When we have N ABIs, there are N^2 cases of mutual calls between ABIs, which will be very complicated to maintain in the future.
Also, the purpose of opening register ABI to users is to improve the performance of handwritten assembly. If the overhead of stack-based ABI is high, in this case, you can consider writing a Go program instead of assembly code, and the compiler will generate register-based ABI. If the overhead of handwritten assembly code inself is very high, the overhead of stack-based ABI is negligible.
So I think it is better not to open register ABI to users. Thank you.
I think RISCV is done. @mengzhuo could you confirm?
Move the rest to 1.20. (Or perhaps we want to close this and open separate issues for what else we want to do.)
I think RISCV is done. @mengzhuo could you confirm?
Move the rest to 1.20. (Or perhaps we want to close this and open separate issues for what else we want to do.)
Yes, it's done and thank you for your help!
The only tasks remaining here are a handful of clean-ups. We should probably open separate issues to track those and close this, but for the moment I'm just going to move to this 1.21.
Since this has been punted a few times, moving this to Backlog. Please comment if you disagree. Thanks!
Change https://go.dev/cl/521781 mentions this issue: cmd/compile: update loong64 CALL* ops
Change https://go.dev/cl/521788 mentions this issue: cmd/compile: fix If lowering on loong64
Change https://go.dev/cl/521786 mentions this issue: runtime: add regABI support in memclr and memmove functions on loong64
Change https://go.dev/cl/521779 mentions this issue: cmd/compile/internal: add register info for loong64 regABI
Change https://go.dev/cl/521783 mentions this issue: runtime: support regABI and add spill functions in runtime for loong64
Change https://go.dev/cl/521787 mentions this issue: cmd/internal/obj: set morestack arg spilling and regabi prologue on loong64
Change https://go.dev/cl/521778 mentions this issue: internal/abi: define loong64 regABI constants
Change https://go.dev/cl/521777 mentions this issue: cmd/compile,cmd/internal,runtime: change registers on loong64 to avoid regABI arguments
Change https://go.dev/cl/521775 mentions this issue: cmd/compile, cmd/internal, runtime: change the registers used by the duff device for loong64
Change https://go.dev/cl/521785 mentions this issue: internal/bytealg: add regABI support in bytealg functions on loong64
Change https://go.dev/cl/521782 mentions this issue: runtime: make duff device as ABIInternal for loong64
Change https://go.dev/cl/521780 mentions this issue: cmd/compile/internal: add spill support for loong64 regABI
Change https://go.dev/cl/521784 mentions this issue: reflect, runtime: add reflect support for regABI on loong64
Change https://go.dev/cl/521789 mentions this issue: runtime/internal/syscall: use ABIInternal for Syscall6 on loong64
Change https://go.dev/cl/521776 mentions this issue: cmd/compile: add ABI register definations for loong64
Change https://go.dev/cl/521790 mentions this issue: cmd/compile, internal/buildcfg: enable regABI on loong64, and add loong64 in test func hasRegisterABI
I propose that we switch the Go internal ABI (used between Go functions) from stack-based to register-based argument and result passing for Go ~1.16~ 1.17.
I lay out the details of our proposal and the work required in this document.
The ABI specification can be found here.
This was previously proposed in #18597, where @dr2chase did some excellent prototyping work that our new proposal builds on. With multiple ABI support, we’re now in a much better position to execute on this without breaking compatibility with the existing body of Go assembly code. I’ve opened this new issue to focus on discussion of our new proposal.
/cc @dr2chase @danscales @thanm @cherrymui @mknyszek @prattmic @randall77
An incomplete and evolving list of tasks:
defer recover()
(@cherrymui, CL)RegEntryTmp
registers in prologue (@mknyszek, CL)WriteFuncMap
) (@dr2chase, CL)cgo_unsafe_args
generate an ABI0 function (or an ABIInternal-with-no-registers function) (@cherrymui, CL)High-priority non-critical path
funcPC
always return the "native" PC of a function (maybe also introduceABIOther
) (@cherrymui, CL)funcPC
is inargs_stackmap
in ABIInternal functions (because it's for ABI0) (CL)reflect.ValueOf(fn).Pointer()
to get the PC of an assembly function will now return the PC of the ABI wrapperEnabling steps
Testing
reflect.{ValueOf(target),MakeFunc(x, target),Method(x)}.{Call,Interface}
, called fromdefer
, called fromgo
, called as a finalizerdefer
in a test function (check arguments, modify results)MoveStackOnNextCall
, assertions for pointer-to-stack/pointer-to-heap, assertions for live/dead (@aclements, CL)Post-MVP
Cleanup (can be done later)
go
in runtime (context)ir.Func
to functionir.Name
s (context)firstpos
inssa.go
– sometimes it's late.