Opening this for discussion, as requested by @bradfitz.
In the new codegen test harness, code generation tests on architectures that have multiple "flavours" (like 386, with GO386={387,sse2}), look like this:
func sqrt(x float64) float64 {
// 386:"FSQRT|SQRTSD" (387 or sse2)
return math.Sqrt(x)
}
Basically we just OR in the regex the ops from all the possible flavours. The test harness will compile sqrt with GOARCH=386 set, and that will default to generating sse2 ops (the default for 386), unless the environment also happen to have GO386=387 set, and in that case 387 ops will be generated.
This is somewhat brittle and has broken builders in the past, because GO386=387 is usually not set when running the codegen tests locally (except on a 387 machine), and we don't have a 387 trybot; so we only notice 386-related mistakes when they break the 387 builder. A similar problem may arise with the arm flavours (we have three: GOARM={5,6,7}), although this hasn't happened in practice (yet).
One possible solution is to make the codegen test harness compile each test that contains a 386 tag two times: first with GO386 set to sse2, then to 387. This will allow us to reliably catch and correct sse2-centric assumption in the 386 test regexps, even by just running the codegen tests locally. The downside is that the codegen tests will be a little slower.
Opinions? @randall77 @cherrymui @rasky @josharian
Opening this for discussion, as requested by @bradfitz.
In the new codegen test harness, code generation tests on architectures that have multiple "flavours" (like 386, with
GO386={387,sse2}), look like this:Basically we just OR in the regex the ops from all the possible flavours. The test harness will compile
sqrtwithGOARCH=386set, and that will default to generatingsse2ops (the default for386), unless the environment also happen to haveGO386=387set, and in that case 387 ops will be generated.This is somewhat brittle and has broken builders in the past, because
GO386=387is usually not set when running the codegen tests locally (except on a 387 machine), and we don't have a 387 trybot; so we only notice 386-related mistakes when they break the 387 builder. A similar problem may arise with the arm flavours (we have three:GOARM={5,6,7}), although this hasn't happened in practice (yet).One possible solution is to make the codegen test harness compile each test that contains a
386tag two times: first withGO386set tosse2, then to387. This will allow us to reliably catch and correctsse2-centric assumption in the386test regexps, even by just running the codegen tests locally. The downside is that the codegen tests will be a little slower.Opinions? @randall77 @cherrymui @rasky @josharian