In ARM64 ABI, R18 is the "platform register", the use of which is OS specific. The OS could choose to reserve this register. In practice, it seems fine to use R18 on Linux (at least for now), but not on darwin (iOS).

On darwin, the tests typically fail reliably when R18 is accidentally used. But the failure is not directly connected to R18 usage. I guess the kernel may simply scribble on R18 at any point of the program. If the user is not aware of the R18 issue, it is not very easy to find the cause.

We have a darwin/arm64 builder, but it is not a trybot (and probably hard to make it one). Given the status of the darwin/arm64 builder, it often takes a while to catch the problem after the CL submitted.

There are a few occurrences in recent CLs that the use of R18 breaks darwin/arm64.
https://golang.org/cl/77831 (fixed by https://golang.org/cl/98896)
https://golang.org/cl/76270 (caught during review)
https://golang.org/cl/99755 (reverted)
And there may be code not in the Go standard library that may also have this problem.

Our compiler does already not use R18. For assembly code, it is documented in https://tip.golang.org/doc/asm#arm64 that R18 is reserved, but there is no protection in the toolchain.

So, should we just reject the use of R18 in our assembler?

Or, should we reject it only when building for darwin/arm64? To catch the error early, we would need at least an iOS cross-compiling trybot. I'm not sure whether this is easy to do. And the use of R18 would make the code less portable.

Or, if there is still desired use of R18, say, using the Go assembler to write code that runs in kernel space, should we rename R18 to R18_YES_I_RELLAY_WANT_TO_USE_IT, so it is still available, but not likely to be accidentally used.