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

cmd/asm,cmd/compile,cmd/link,cmd/objdump: ppc64 ISA 3.1 support #44549

Closed
pmur opened this issue Feb 23, 2021 · 14 comments
Closed

cmd/asm,cmd/compile,cmd/link,cmd/objdump: ppc64 ISA 3.1 support #44549

pmur opened this issue Feb 23, 2021 · 14 comments
Assignees
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@pmur
Copy link
Contributor

pmur commented Feb 23, 2021

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:

  • More crypto instructions
  • Support for PC relative load/store/add immediate
  • Prefixed instructions (two word instructions) for larger load/store/add immediate

The latter two features will require a bit of preparation work in the ppc64 backend. Go 1.17 development will focus on preparation work.

@cagedmantis cagedmantis added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-ppc64x labels Feb 24, 2021
@cagedmantis cagedmantis added this to the Backlog milestone Feb 24, 2021
@laboger
Copy link
Contributor

laboger commented Apr 7, 2021

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?

@pmur
Copy link
Contributor Author

pmur commented Apr 7, 2021

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.

@Robert-M-Muench
Copy link

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.

@gopherbot
Copy link

Change https://golang.org/cl/347050 mentions this issue: cmd/internal/obj/ppc64: support alignment of prefixed insn

@gopherbot
Copy link

Change https://golang.org/cl/350152 mentions this issue: cmd/internal/obj/ppc64: rework argument classifications

@gopherbot
Copy link

Change https://golang.org/cl/352791 mentions this issue: internal/cpu, internal/buildcfg: support GOPPC64=power10

@gopherbot
Copy link

Change https://golang.org/cl/355149 mentions this issue: cmd/link: support ppc64 prefixed relocations for power10

@gopherbot
Copy link

Change https://golang.org/cl/355150 mentions this issue: cmd/internal/obj: Use prefix insn in MOV* opcodes for GOPPC64=power10

gopherbot pushed a commit that referenced this issue Oct 12, 2021
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>
gopherbot pushed a commit that referenced this issue Oct 21, 2021
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>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@gopherbot
Copy link

Change https://go.dev/cl/419535 mentions this issue: cmd/internal/obj/ppc64: add ISA 3.1 instructions

@gopherbot
Copy link

Change https://go.dev/cl/419534 mentions this issue: cmd/asm,cmd/internal/obj/ppc64: recognize ppc64 ISA 3.1 MMA registers

gopherbot pushed a commit that referenced this issue Aug 18, 2022
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>
gopherbot pushed a commit that referenced this issue Sep 7, 2022
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>
gopherbot pushed a commit that referenced this issue Sep 15, 2022
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>
gopherbot pushed a commit that referenced this issue Nov 3, 2022
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>
gopherbot pushed a commit that referenced this issue Feb 28, 2023
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>
@pmur pmur self-assigned this May 1, 2023
@gopherbot
Copy link

Change https://go.dev/cl/490955 mentions this issue: cmd/link/internal/ppc64: initial support for importing PCrel relocs

@gopherbot
Copy link

Change https://go.dev/cl/492617 mentions this issue: cmd/link/internal/ppc64: link ELFv2 objects built with -mcpu=power10

gopherbot pushed a commit that referenced this issue May 16, 2023
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>
@pmur
Copy link
Contributor Author

pmur commented Jun 7, 2023

I think this support is effectively complete with the release of Go 1.21.

@pmur pmur closed this as completed Jun 7, 2023
@gopherbot
Copy link

Change https://go.dev/cl/501358 mentions this issue: doc/go1.21: document GOPPC64=power10 changes

gopherbot pushed a commit that referenced this issue Jun 13, 2023
For #44549

Change-Id: I1af1d4bbd01a4571a32815bfea16bc395524551a
Reviewed-on: https://go-review.googlesource.com/c/go/+/501358
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Eli Bendersky <eliben@google.com>
@dmitshur dmitshur removed this from the Backlog milestone Dec 8, 2023
@dmitshur dmitshur added this to the Go1.21 milestone Dec 8, 2023
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants