all: drop GO386=387 support in Go 1.16

[aclements]

I propose dropping 387 floating-point support and requiring SSE2 support for GOARCH=386 in the native gc compiler for Go 1.16. This would raise the minimum GOARCH=386 requirement to the Intel Pentium 4 (released in 2000) or AMD Opteron/Athlon 64 (released in 2003).

We would need to pre-announce this in the 1.15 release notes. (I've put it in the 1.15 milestone for this reason.)

There are several benefits to doing this:

1. While 387 support isn’t a huge maintenance burden, it does take time away from performance and feature work and represents a fair amount of latent complexity.
2. 387 support has been a regular source of bugs (cmd/compile: constant propagation in compiler converts signaling NaN to quiet NaN #36400, cmd/compile: 387 quietens signalling NaNs during compilation #27516, cmd/compile: invalid instruction error for FMOVD when compiling for 387 #22429, math: math on 387 does not match float64 due to extended exponents #17357, cmd/compile: Illegal instruction 'fucomip' on 386 with GO386=387 #13923, possible non-387 instructions in a GO386=387 build #12970, cmd/8c: use of prefetchnta requires SSE #4798, just to name a few).
3. 387 bugs often go undetected for a long time because we don’t have builders that support only 387 (so unsupported instructions can slip in unnoticed).
4. Raising the minimum requirement to SSE2 would allow us to also assume many other useful architectural features, such as proper memory fences and 128 bit registers, which would simplify the compiler and runtime and allow for much more efficient implementations of core functions like memmove on 386.
5. We’re exploring switching to a register-based calling convention in Go 1.16, which promises significant performance improvements, but retaining 387 support will definitely complicate this and slow our progress.

The gccgo toolchain will continue to support 387 floating-point, so this remains an option for projects that absolutely must use 387 floating-point.

I proposed this on golang-nuts to get feedback on significant uses of GO386=387, particularly for which using gccgo would not be a viable option.

[gopherbot]

Change https://golang.org/cl/243137 mentions this issue: doc/go1.15: announce GO386=387 deprecation

[aclements]

We should wait a little longer for public comment, but I've gone ahead and prepared the pre-announcement for the release notes. (We could also submit the release notes change and roll it back if necessary.)

Nick Craig-Wood pointed out on golang-nuts that we should make sure GO386=387 fails with a useful error message if we do drop it (rather than, say, starting to ignore the GO386 environment variable entirely).

[mvdan]

Perhaps a silly question, but would this affect GOARCH=amd64 at all?

[randall77]

@mvdan, no it would not.

[beoran]

I guess I am the only one who still has such an old computer. Emulated coprocessor support is also still useful for certain embedded systems. I would keep the feature around for a few more years.

[martisch]

It is known that systems still exists that do not support SSE2. I have several too. It would be interesting if there are users of them relying on current versions of Go for more than hobbyist use and if they cant use gccgo.

[aclements]

I've gone ahead and submitted the deprecation notice to the 1.15 release notes. However, this issue is still in proposal review. If it does get declined, we can revert the CL. I've asked for this to get reviewed in next week's proposal review meeting.

[rsc]

This went into the proposal minutes last week, and @aclements mailed it to golang-nuts and golang-dev as well. Let's leave this open another week before moving to likely accept, but there doesn't seem to be much pushback here.

[rsc]

Based on the discussion above, this seems like a likely accept.
So long, 387, and thanks for all the floating-point errors.