#63871, which found a PSHUFB (v2+) not guarded by any instruction set checks in a crypto/tls dependency, shows that we are not testing GOAMD64=v1 terribly well. That is, it is possible to use newer instructions in Go packages accidentally, without breaking any tests. If we are going to provide GOAMD64=v1 it seems like we should have a test that it works as advertised.

(To be clear, it is OK to emit these instructions when GOAMD64=v1, which is our default build mode, but only if they are guarded by an instruction set check before use. I don't see any such check in that case.)

I don't believe we have any v1 hardware to run on, and keeping access to that hardware would become progressively difficult in the future. I've heard a suggestion of using QEMU, but that's fraught with all sorts of problems. Instead I wonder if we should set up a stronger, builder version of cmd/compile/internal/amd64's TestGoAMD64v1. That test does the following:

1. Replace any non-v1 instruction with a breakpoint instruction, found by disassembling the binary.
2. Set GODEBUG environment variables to instruct code not to use post-v1 features.
3. Run itself (its own test binary).

The stronger version would set some environment variable on a v1 builder that would cause the assembler to do two things:

1. Replace all non-v1 instructions with breakpoints.
2. Replace CPUID with a call to a simulation function that sets the registers to look like only v1 features are present.

This would apply during all of all.bash, not just during cmd/compile/internal/amd64.test. And it wouldn't depend on our getting the GODEBUG variables correct. We'd need a table of instruction->feature set for the assembler. We could set up the same for v2, v3.

Might be a good fixit week activity.