Question on the multi-versioning approach: if the AST rewrite creates N specialized copies of every function that mentions the SIMD types, doesn't binary size scale with the number of SIMD-touching functions? For generic hot paths (helpers parameterized over vector widths, instantiated across many call sites) that could multiply code size noticeably. Is there dedup when two specialized copies would be identical, or has anyone measured the binary-size cost on a real codebase?
Binary size only scales for the simd-touching platforms, with scaling depending on platform. Each platform gets emulation+number-of-variants. Emulation is there as an option, primarily for testing (do you trust us? I don't trust us). So wasm is 2x, amd64 is 4x, arm64 is currently 2x but should be 4x in the near future. ppc64 ought to be 2x, maybe 3x, don't know their variants story. Loong64 will be 3x. But only the SIMD-touching stuff is replicated, and N-1 copies of the replicated code are never executed by a given program execution.
SVE and RVV, because they are "scalable", may end up with a larger amount of replication.
Go uses fixed-size stack frames, so spill space is fixed size, etc. We could "just" fix this limitation, or we could generate multiple sizes for what actually exists in the wild, with a masked implementation for longer. So, SVE would end up with 0 (emulation), 128, 256, and 512-masked, plus (as arm64) would also have NEON and NEON-noclmul (Raspberry Pi). I'm not sure what sizes exist for RVV.
