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.

[bradfitz]

One data point: just today somebody asked for 387 binaries in tailscale/tailscale#651

We already cross-compile a number of architectures (https://pkgs.tailscale.com/unstable/#static) and it's easy to add 387 to that list. If we had to use gccgo, though, it's a bit harder. Perhaps add some docs linked from the release notes pointing to gccgo instructions for building static 387 binaries?

[ianlancetaylor]

To build a static executable with gccgo: go build -compiler=gccgo -gccgoflags=-static.

But note that gccgo executables use the C libraries, so static executables on GNU/Linux systems have some limitations, as glibc generally expects to be dynamically linked. Specifically not all /etc/nsscache.conf values are supported, unless the dynamic C library is also present at run time.

[martisch]

The most feedback to keep support seems to come from users with AMD Geode GX/LX (the kind with MMX but not SSE or SSE2) boards still used in the embedded space (e.g. routers like the ALIX boards).

Im in favor of dropping 387. As an alternative go1.16 could be made to reinterpret GO386=387 to mean use softfloat support instead of 387 or SSE2 instructions. This would make ordinary go programs on 387 hardware still work, but slower. It would make the register based calling convention still easier as other platforms (e.g. arm and mips) also require softfloat support. We would also have a mainstream platform for builders to test the softfloat code paths frequently.

The upside is that e.g. Athlon XP and Pentium II/III (there were quite alot produced in the Windows XP time) keep on working and linux distros dont need to switch away from go gc to gogcc for their package builders for 386 distros supporting older hardware. This would allow linux distros to keep on using the same build/verification processes in place for 386 and amd64.

For verifying no newer instructionsets are used we could potentially use something like:
https://software.intel.com/content/www/us/en/develop/articles/intel-software-development-emulator.html

[rsc]

No change in consensus, so accepted.

[gopherbot]

Change https://golang.org/cl/257277 mentions this issue: cmd/compile: prevent 387+float32+pie from clobbering registers

[gopherbot]

Change https://golang.org/cl/257207 mentions this issue: [release-branch.go1.15] cmd/compile: prevent 387+float32+pie from clobbering registers

[gopherbot]

Change https://golang.org/cl/257208 mentions this issue: [release-branch.go1.14] cmd/compile: prevent 387+float32+pie from clobbering registers

[gopherbot]

Change https://golang.org/cl/259449 mentions this issue: dashboard: remove linux-386-387 builder

[randall77]

We replaced 387 support with softfloat support GO386=softfloat in CLs 260017 and 260137.
If anyone has a machine without SSE support, please try tip and let us know if it works.
@beoran

[gopherbot]

Change https://golang.org/cl/342895 mentions this issue: dashboard, cmd/gomote: remove the linux-386-387 builder