cmd/compile/abi-internal: declare R14 completely fixed

Currently, we allow R14, the current goroutine pointer, to be
clobbered in function bodies as long as the function restores it. This
is unnecessary complexity and could lead to confusing inconsistencies
with other architectures that can't simply restore it from TLS.

Updates #40724.

Change-Id: I4c052f0dd0b31d31afeb0c5aff05c314d7a852f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/309009
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

diff --git a/src/cmd/compile/abi-internal.md b/src/cmd/compile/abi-internal.md
index aa61fcc5441757d7b67242649ad64c79d789fa83..f901e707be3d6147f29e5355e7a8a55a09371e59 100644 (file)
--- a/src/cmd/compile/abi-internal.md
+++ b/src/cmd/compile/abi-internal.md
@@ -408,7 +408,7 @@ Special-purpose registers are as follows:
 | RDX | Closure context pointer | Scratch | Scratch |
 | R12 | Scratch | Scratch | Scratch |
 | R13 | Scratch | Scratch | Scratch |
-| R14 | Current goroutine | Same | Scratch |
+| R14 | Current goroutine | Same | Same |
 | R15 | GOT reference temporary if dynlink | Same | Same |
 | X15 | Zero value | Same | Scratch |
 
@@ -424,6 +424,13 @@ While this adds one byte to every function prologue, it is hardly ever
 accessed outside the function prologue and we expect making more
 single-byte registers available to be a net win.
 
+*Rationale*: We could allow R14 (the current goroutine pointer) to be
+a scratch register in function bodies because it can always be
+restored from TLS on amd64.
+However, we designate it as a fixed register for simplicity and for
+consistency with other architectures that may not have a copy of the
+current goroutine pointer in TLS.
+
 *Rationale*: We designate X15 as a fixed zero register because
 functions often have to bulk zero their stack frames, and this is more
 efficient with a designated zero register.