all: more thorough testing of GOAMD64=v1 instruction limits #63872
Labels
Builders
x/build issues (builders, bots, dashboards)
compiler/runtime
Issues related to the Go compiler and/or runtime.
help wanted
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
#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:
The stronger version would set some environment variable on a v1 builder that would cause the assembler to do two things:
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.
The text was updated successfully, but these errors were encountered: