Split out from https://github.com/golang/go/issues/37174#issuecomment-683899466
So once we stop supporting releases <10.15.6, we can get rid of the VZEROUPPER patch.
cc @randall77 @dmitshur
Comment From: dmitshur
Apple has been making a new major macOS version each year, and Go has been dropping support for old macOS versions at the same rate. So we can estimate.
Go 1.11 started to require macOS 10.10 or later. Go 1.13 started to require macOS 10.11 or later. Go 1.15 started to require macOS 10.12 or later. If that rate doesn't change, Go 1.23 will start to require macOS 10.16 (aka macOS 11.0) or later, and this optimization can be applied then.
Comment From: HenkPoley
Potentially this issue was reintroduced (elsewhere?) in macOS 10.15.7 (19H15?): https://twitter.com/Cyan4973/status/1327023284974538754
Comment From: randall77
For future self, make sure the reproducers in #37174 perform ok before removing the VZEROUPPER.
Comment From: randall77
Just upgraded to 10.15.7 and it looks still fixed to me.
(The C/asm reproducer runs at the same speed regardless of whether the vzeroupper is commented out or not.)
Comment From: mdempsky
According to https://golang.org/doc/go1.16, Go 1.17 will still support macOS 10.13. So should this be deferred to Go 1.18 (or Go 1.23, per @dmitshur)?
Comment From: dmitshur
I understand this isn't so critical that we need to re-evaluate and bump every 6 months, so I'll put this in a future Go 1.23 milestone. If something changes before then, we can revisit this.
Comment From: gopherbot
This issue is currently labeled as early-in-cycle for Go 1.23. That time is now, so a friendly reminder to look at it again.
Comment From: gopherbot
Change https://go.dev/cl/560955 mentions this issue: runtime: remove VZEROUPPER in asyncPreempt on darwin/amd64
Comment From: cuonglm
I could not find a Mac Intel for testing https://go-review.googlesource.com/c/go/+/560955, any help on verifying the CL is welcome.
cc @golang/darwin