Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: drop GO386=387 support in Go 1.16 #40255

Open
aclements opened this issue Jul 16, 2020 · 13 comments
Open

all: drop GO386=387 support in Go 1.16 #40255

aclements opened this issue Jul 16, 2020 · 13 comments

Comments

@aclements
Copy link
Member

@aclements aclements commented Jul 16, 2020

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 (#36400, #27516, #22429, #17357, #13923, #12970, #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.

@aclements aclements added this to the Go1.15 milestone Jul 16, 2020
@gopherbot gopherbot added the Proposal label Jul 16, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Jul 16, 2020

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

@aclements
Copy link
Member Author

@aclements aclements commented Jul 16, 2020

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).

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jul 16, 2020
@mvdan
Copy link
Member

@mvdan mvdan commented Jul 16, 2020

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

@randall77
Copy link
Contributor

@randall77 randall77 commented Jul 16, 2020

@mvdan, no it would not.

@beoran
Copy link

@beoran beoran commented Jul 18, 2020

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
Copy link
Member

@martisch martisch commented Jul 18, 2020

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.

@rsc rsc moved this from Incoming to Active in Proposals Jul 22, 2020
@rsc rsc changed the title proposal: drop GO386=387 support in Go 1.16 proposal: all: drop GO386=387 support in Go 1.16 Jul 22, 2020
gopherbot pushed a commit that referenced this issue Jul 23, 2020
For #40255.
Updates #37419.

Change-Id: If9210c855cc2eea079e7e469463d4203888748f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/243137
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@aclements
Copy link
Member Author

@aclements aclements commented Jul 23, 2020

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
Copy link
Contributor

@rsc rsc commented Jul 29, 2020

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
Copy link
Contributor

@rsc rsc commented Aug 5, 2020

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

@rsc rsc moved this from Active to Likely Accept in Proposals Aug 5, 2020
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 7, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 7, 2020

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
Copy link
Member

@martisch martisch commented Aug 10, 2020

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

@andybons andybons modified the milestones: Go1.15, Go1.16 Aug 11, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Aug 12, 2020

No change in consensus, so accepted.

@rsc rsc moved this from Likely Accept to Accepted in Proposals Aug 12, 2020
@rsc rsc changed the title proposal: all: drop GO386=387 support in Go 1.16 all: drop GO386=387 support in Go 1.16 Aug 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants
You can’t perform that action at this time.