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/asm,cmd/compile,cmd/link,cmd/objdump: ppc64 ISA 3.1 support #44549
Comments
There is work being done to provide support in the assembler and disassembler on ppc64x for some instructions in ISA 3.1. The Go compiler will not be generating any of these instructions yet but they can be assembled and verified that they assemble to the correct instruction bits. Based on the recent comment in golang-dev about the Go 1.17 freeze, should this be marked as part of the Go 1.17 milestone? |
I would like to get the cmd/objdump support in for 1.17. It would be nice to get support for aligning prefixed opcodes in cmd/asm, but that is not a release blocker. |
A bit OT: Does/Can the Go compiler generate instructions for float128 FPU calculations on this architecture? I wonder because there is no float128 type. One of the big advantages of this architecture is the native float128 support. |
Change https://golang.org/cl/347050 mentions this issue: |
Change https://golang.org/cl/350152 mentions this issue: |
Change https://golang.org/cl/352791 mentions this issue: |
Change https://golang.org/cl/355149 mentions this issue: |
Change https://golang.org/cl/355150 mentions this issue: |
Insert machine NOPs when a prefixed instruction crosses a 64B boundary. ISA 3.1 prohibits prefixed instructions being placed across them. Such instructions generate SIGILL if executed. Likewise, adjust the function alignment to guarantee such instructions can never cross one. And, don't pad the PC based on alignment. The linker can fit these more optimally. Likewise, include the function alignment when printing function debug information. This is needed to verify function alignment happens. Updates #44549 Change-Id: I434fb0ee4e984ca00dc4566f7569c3bcdf93f910 Reviewed-on: https://go-review.googlesource.com/c/go/+/347050 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This introduces a number of new classifications which will make it easier to generate functions to assemble the new instructions of ISA 3.1, and potentially earlier versions. No code generation changes should occur as a result of these. These allow finer control over how an opcode is matched to an optab entry. Literal values are now classified based on the smallest number of bits needed to encode, and matching rules will accept a literal if it can be zero/sign extended to fit a larger literal class. Likewise, support classifying even register numbers for GPR, VSX, and FPR instructions. Some instructions require and even/odd register pair, and these are usually represented by specifying the even register, and similarly encoded. Likewise, add a unit test for the argument classifier function (aclass). This caught an off-by-one bug in aclass which is also fixed. Updates #44549 Change-Id: Ia03013aea8b56c4d59b7c3812cdd67ddb3b720b9 Reviewed-on: https://go-review.googlesource.com/c/go/+/350152 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
Change https://go.dev/cl/419535 mentions this issue: |
Change https://go.dev/cl/419534 mentions this issue: |
This does not enable any new functionality. It should behave identically to GOPPC64=power9. Updates #44549 Change-Id: I9a860544527fcfe97cbaf89686459d40dcf9593e Reviewed-on: https://go-review.googlesource.com/c/go/+/352791 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Allow the assembler frontend to match MMA register arguments added by ISA 3.1. The prefix "A" (for accumulator) is chosen to identify them. Updates #44549 Change-Id: I363e7d1103aee19d7966829d2079c3d876621efc Reviewed-on: https://go-review.googlesource.com/c/go/+/419534 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Paul Murphy <murp@ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Use ppc64map (from x/arch) to generate ISA 3.1 support for the assembler. A new file asm9_gtables.go is added which contains generated code to encode ISA 3.1 instructions, a function to assist filling out the oprange structure, a lookup table for the fixed bits of each instructions, and a slice of string name. Generated functions are shared if their bitwise encoding match, and the translation from an obj.Prog structure matches. The generated file is entirely self-contained, and does not require regenerating any other files for changes within it. If opcodes in a.out.go are reordered or changed, anames.go must be updated in the same way as before. Future improvements could shrink the generated opcode table to 32 bit entries as there is much less variation of the encoding of the prefix word, but it is not always identical for instructions which share a similar encoding of arguments (e.g PLWA and PLWZ). Updates #44549 Change-Id: Ie83fa02497c9ad2280678d68391043d3aae63175 Reviewed-on: https://go-review.googlesource.com/c/go/+/419535 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Jenny Rakoczy <jenny@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Jenny Rakoczy <jenny@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Jenny Rakoczy <jenny@golang.org>
Handle emitting (to ld) or resolving commonly used ELFv2 1.5 relocations. The new ISA provides PC relative addressing with 34 bit signed addresses, and many other relocations which can replace addis + d-form type relocations with a single prefixed instruction. Updates #44549 Change-Id: I7d4f4314d1082daa3938f4353826739be35b0e81 Reviewed-on: https://go-review.googlesource.com/c/go/+/355149 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Paul Murphy <murp@ibm.com>
As background, Power10 adds prefixed load, store, and add immediate instructions which encode 34b signed displacements. Likewise, they also give the option to compute addresses against the PC. This enables using simpler PC relative (PC-rel) relocations instead of maintaining a dedicated pointer (the TOC) to the code/data blob on PPC64/linux. Similary, there are several Go opcodes where it can be advantageous to use prefixed instructions instead of composite sequences like oris/ori/add to implement "MOVD <big const>, Rx" or "ADD <big const>, Rx, Ry", or large offset load/stores like "MOVD <big constant>(Rx), Ry" using the same framework which dynamically configures optab. When selecting prefixed instruction forms, the assembler must also use new relocations. These new relocations are always PC-rel by design, thus code assembled as such has no implicit requirement to maintain a TOC pointer when assembling shared objects. Thus, we can safely avoid situations where some Go objects use a TOC pointer, and some do not. This greatly simplifies linking Go objects. For more details about the challenges of linking TOC and PC-rel compiled code, see the PPC64 ELFv2 ABI. The TOC pointer in R2 is still maintained in those build configurations which previously required it (e.x buildmode=pie). However, Go code built with PC-rel relocations does not require the TOC pointer. A future change could remove the overhead of maintaining a TOC pointer in those build configurations. This is enabled only for power10/ppc64le/linux. A final noteworthy difference between the prefixed and regular load/store instruction forms is the removal of the DS/DQ form restrictions. That is, the immediate operand does not need to be aligned. Updates #44549 Change-Id: If59c216d203c3eed963bfa08855e21771e6ed669 Reviewed-on: https://go-review.googlesource.com/c/go/+/355150 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Run-TryBot: Paul Murphy <murp@ibm.com>
Change https://go.dev/cl/490955 mentions this issue: |
Change https://go.dev/cl/492617 mentions this issue: |
Specifically, objects built via cgo using CGO_CFLAGS="-O2 -g -mcpu=power10". These use new relocations defined by ELFv2 1.5, and the R_PPC64_REL24_NOTOC relocation. These objects contain functions which may not use a TOC pointer requiring the insertion of trampolines to use correctly. The relocation targets of these ELFv2 objects may also contain non-zero values. Clear the relocated bits before setting them. Extra care is taken if GOPPC64 < power10. The R_PPC64_REL24_NOTOC reloc existed prior to ELFv2 1.5. The presence of this relocation itself does not imply a power10 target. Generate power8 compatible stubs if GOPPC64 < power10. Updates #44549 Change-Id: I06ff8c4e47ed9af835a7dcfbafcfa4c538f75544 Reviewed-on: https://go-review.googlesource.com/c/go/+/492617 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
I think this support is effectively complete with the release of Go 1.21. |
Change https://go.dev/cl/501358 mentions this issue: |
This is a container task for implementing support for the upcoming POWER10 processor.
ISA 3.1 documentation can be found here.
Notable additions we would like to support in golang:
The latter two features will require a bit of preparation work in the ppc64 backend. Go 1.17 development will focus on preparation work.
The text was updated successfully, but these errors were encountered: