proposal: simd: rename low-level SIMD package to simd/archsimd (GOEXPERIMENT)

[aclements]

Proposal Details

Accepted proposal #73787 proposes a multi-level approach to SIMD support in Go. That proposal focuses on the first phase, which is a low-level, architecture-dependent package, but lays out a broader plan to also support a high-level, fully portable (but more narrow) SIMD package.

In that proposal, we named the low-level SIMD package simply simd, and did not propose a name for the high-level SIMD package.

I propose we reserve the top-level simd package name for the high-level, portable API, and move the low-level, architecture-dependent API to simd/archsimd. All of this would remain gated by GOEXPERIMENT=simd for now.

Alternatives considered

We could put both levels in the same package. We rejected this idea because it would result in a cluttered package and make it far less clear what's portable and what isn't. By separating the packages, it is immediately apparent which API code is using.

We could create a top-level package, say cpu, for CPU-specific functionality. cpu would be used to implement simd (and potentially other portable packages), much like how syscall is the OS-specific package underlying the portable APIs in os and other std packages. This idea is based on the observation that we may want to add other CPU-specific APIs in the future, and this would give them a home. The boundary of "what is SIMD" and "what is not SIMD" can be quite fuzzy: for example, the x86 GF2P8AFFINEQB instruction and the proposed RISC-V bmatxor instruction do essentially the same thing, but GF2P8AFFINEQB operates only on vectors of multiple inputs, and bmatxor operations only on scalar inputs. Should one be accessible just because it's technically "SIMD" while the other is not? This is a tempting alternative, but we ultimately rejected the idea for two reasons: 1. our low-level SIMD API is not a simple export of the assembly instructions, it's actually itself semi-portable and very much designed for SIMD, 2. a cpu package (or arch or asm) simply seems too tempting, and we want to actively encourage using portable APIs and actively discourage using non-portable APIs.

cc @cherrymui @dr2chase @JunyangShao