Considering dropping GO386=387

Austin Clements

unread,

Jul 14, 2020, 8:56:58 AM7/14/20

to golang-nuts

Hi everyone. We’re exploring the possibility of dropping 387 floating-point support and requiring SSE2 support for GOARCH=386 in the native gc compiler, potentially in 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).

There are several reasons we’re considering this:

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.
387 support has been a regular source of bugs (#36400, #27516, #22429, #17357, #13923, #12970, #4798, just to name a few).
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).
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.
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.

We’d like to know if there are still significant uses of GO386=387, particularly for which using gccgo would not be a viable option.

Thanks!

Nick Craig-Wood

unread,

Jul 15, 2020, 1:20:50 PM7/15/20

to golang-nuts

I make a GO386=387 build for rclone, eg

https://github.com/rclone/rclone/issues/437

People love running rclone on ancient computers to rescue data off them I guess.

This would affect a very small percentage of users and there are always older versions of rclone they can use so I'm not too bothered if support is dropped.

I haven't tried compiling rclone with gccgo for a while.

It would be helpful if the build fails rather than silently ignoring the GO386 flag if this proposal does go forward.

Austin Clements

unread,

Jul 16, 2020, 1:47:06 PM7/16/20

to Nick Craig-Wood, golang-nuts

Thanks for that data point, Nick. It's a good idea to make the build fail if GO386 is set to 387 if we drop support. It already fails if GO386 is set to any unsupported value, but we could continue to check GO386 even though there would only be one supported value, and perhaps give a nicer error if it's set to 387.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/babd66fd-fe7f-4840-b1aa-8cb32b499b67n%40googlegroups.com.

Hunter Herman

unread,

Jul 17, 2020, 3:54:09 AM7/17/20

to golang-nuts

Hi Austin! I’m very curious about the register based calling convention you referenced in your email. Could you share more (informal is fine) details?

Ian Lance Taylor

unread,

Jul 17, 2020, 2:21:27 PM7/17/20

to Hunter Herman, golang-nuts

On Fri, Jul 17, 2020 at 12:54 AM Hunter Herman <hunter...@gmail.com> wrote:
>
> Hi Austin! I’m very curious about the register based calling convention you referenced in your email. Could you share more (informal is fine) details?

See https://golang.org/issue/18597 and https://golang.org/issue/27539.

Ian

Hunter Herman

unread,

Jul 18, 2020, 1:23:13 AM7/18/20

to Ian Lance Taylor, golang-nuts

Thank you!

Reply all

Reply to author

Forward