go/src/runtime/asm_amd64.s, branch json-isValidNumber-before

runtime: mark amd64 runtime·rt0_go as NOFRAME

2023-01-25T15:14:29Z

This CL adds the NOFRAME flag to runtime·rt0_go, which should had been added in CL 459395 but didn't and broke fix windows-amd64-2008. Change-Id: I4583f2034bf114e1f7aaddef9ba505f53536c3eb Reviewed-on: https://go-review.googlesource.com/c/go/+/463120 Run-TryBot: Quim Muntal Reviewed-by: Bryan Mills Auto-Submit: Quim Muntal TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui

runtime: use explicit NOFRAME on windows/amd64

2023-01-24T19:29:51Z

This CL marks non-leaf nosplit assembly functions as NOFRAME to avoid relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions without stack were also marked as NOFRAME. Updates #57302 Updates #40044 Change-Id: Ia4d26f8420dcf2b54528969ffbf40a73f1315d61 Reviewed-on: https://go-review.googlesource.com/c/go/+/459395 Reviewed-by: Cherry Mui Run-TryBot: Quim Muntal TryBot-Result: Gopher Robot Reviewed-by: Matthew Dempsky

runtime: switch AMD64's publicationBarrier to ABIInternal

2023-01-24T19:11:33Z

Shrinks a few runtime functions: runtime runtime.mallocgc 2127 -> 2117 (-0.47%) runtime.(*mheap).initSpan 652 -> 639 (-1.99%) runtime.(*mspan).userArenaNextFree 825 -> 808 (-2.06%) file before after Δ % runtime.s 512473 512414 -59 -0.012% total 20843331 20843272 -59 -0.000% Change-Id: Ifaca7abb6db3467b73945fac71496dd7527e6863 Reviewed-on: https://go-review.googlesource.com/c/go/+/462296 Auto-Submit: Keith Randall Run-TryBot: Jakub Ciolek Reviewed-by: Matthew Dempsky TryBot-Result: Gopher Robot Run-TryBot: Keith Randall Reviewed-by: Keith Randall Reviewed-by: Keith Randall

runtime: remove 104 byte stack guard

2023-01-20T04:55:48Z

The number 104 appears to date back to the first implementation of split stacks in https://go.googlesource.com/go/+/b987f7a757f53f460973622a36eebb696f9b5060. That change introduces a 104 byte stack guard. it doesn't makes any sense today. Change-Id: I73069f6d1a827653af63e616f0119fbac809882e GitHub-Last-Rev: bcf900059047548c1709c6d4cf4649a96ad85e57 GitHub-Pull-Request: golang/go#56594 Reviewed-on: https://go-review.googlesource.com/c/go/+/448036 TryBot-Result: Gopher Robot Reviewed-by: Cherry Mui Run-TryBot: Ian Lance Taylor Reviewed-by: Keith Randall Reviewed-by: Keith Randall

runtime,cmd/internal/obj/x86: use TEB TLS slots on windows/amd64

2022-11-14T20:43:12Z

This CL redesign how we get the TLS pointer on windows/amd64. We were previously reading it from the [TEB] arbitrary data slot, located at 0x28(GS), which can only hold 1 TLS pointer. With this CL, we will read the TLS pointer from the TEB TLS slot array, located at 0x1480(GS). The TLS slot array can hold multiple TLS pointers, up to 64, so multiple Go runtimes running on the same thread can coexists with different TLS. Each new TLS slot has to be allocated via [TlsAlloc], which returns the slot index. This index can then be used to get the slot offset from GS with the following formula: 0x1480 + index*8 The slot index is fixed per Go runtime, so we can store it in runtime.tls_g and use it latter on to read/update the TLS pointer. Loading the TLS pointer requires the following asm instructions: MOVQ runtime.tls_g, AX MOVQ AX(GS), AX Notice that this approach is also implemented on windows/arm64. [TEB]: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block [TlsAlloc]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc Updates #22192 Change-Id: Idea7119fd76a3cd083979a4d57ed64b552fa101b Reviewed-on: https://go-review.googlesource.com/c/go/+/431775 Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot Run-TryBot: Quim Muntal Reviewed-by: Michael Knyszek Reviewed-by: Alex Brainman

all: fix spelling

2022-05-18T00:47:29Z

Change-Id: I63eb42f3ce5ca452279120a5b33518f4ce16be45 GitHub-Last-Rev: a88f2f72bef402344582ae997a4907457002b5df GitHub-Pull-Request: golang/go#52951 Reviewed-on: https://go-review.googlesource.com/c/go/+/406843 Run-TryBot: Robert Griesemer TryBot-Result: Gopher Robot Run-TryBot: Ian Lance Taylor Reviewed-by: Ian Lance Taylor Reviewed-by: Robert Griesemer Auto-Submit: Ian Lance Taylor

runtime: check GOAMD64 v4 compatibility on Darwin

2022-04-01T00:05:05Z

Darwin requires a different approach to check AVX512 support. Update #45453 Change-Id: Ia3dfecc04b47aab16f472000e92e46d4fc6d596d Reviewed-on: https://go-review.googlesource.com/c/go/+/365395 Reviewed-by: Keith Randall Run-TryBot: Keith Randall TryBot-Result: Gopher Robot Trust: Heschi Kreinick

runtime: check GOAMD64 compatibility after setting up TLS

2021-11-16T23:52:13Z

We need TLS set up to be able to print an error without crashing. Fixes #49586 Update #45453 Change-Id: I97f0efcd716a8dca614e82ab73f2d855b7277599 Reviewed-on: https://go-review.googlesource.com/c/go/+/364174 Run-TryBot: Keith Randall TryBot-Result: Go Bot Reviewed-by: Martin Möhrmann Trust: Martin Möhrmann Trust: Keith Randall

runtime: check amd64 microarchitecture level at startup

2021-11-02T16:40:04Z

Make Go runtime throw if it's been compiled to assume instruction set extensions that aren't available on the CPU. Updates #48506 Change-Id: Ic4d6696e1cd6b28d389a86fe64e8175ea3ca135a GitHub-Last-Rev: ba338377f549344b416fbd519576e95ce5d523be GitHub-Pull-Request: golang/go#48514 Reviewed-on: https://go-review.googlesource.com/c/go/+/351191 Run-TryBot: Martin Möhrmann TryBot-Result: Go Bot Reviewed-by: Martin Möhrmann Reviewed-by: Keith Randall Trust: Martin Möhrmann

runtime: use RDTSCP for instruction stream serialized read of TSC

2021-08-23T20:32:04Z

To measure all instructions having been completed before reading the time stamp counter with RDTSC an instruction sequence that has instruction stream serializing properties which guarantee waiting until all previous instructions have been executed is needed. This does not necessary mean to wait for all stores to be globally visible. This CL aims to remove vendor specific logic for determining the instruction sequence with CPU feature flag checks that are CPU vendor independent. For intel LFENCE has the wanted properties at least since it was introduced together with SSE2 support. On AMD instruction stream serializing LFENCE is supported by setting an MSR C001_1029[1]=1 on AMD family 10h/12h/14h/15h/16h/17h processors. AMD family 0Fh/11h processors support LFENCE as serializing always. AMD plans support for this MSR and access to this bit for all future processors. Source: https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf Reading the MSR to determine LFENCE properties is not always possible or reliable (hypervisors). The Linux kernel is relying on serializing LFENCE on AMD CPUs since a commit in July 2019: https://lkml.org/lkml/2019/7/22/295 and the MSR C001_1029 to enable serialization has been set by default with the Spectre v1 mitigations. Using an MFENCE on AMD is waiting on previous instructions having been executed but in addition also flushes store buffers. To align the serialization properties without runtime detection of CPU manufacturers we can use the newer RDTSCP instruction which waits until all previous instructions have been executed. RDTSCP is available on Intel since around 2008 and on AMD CPUs since around 2006. Support for RDTSCP can be checked independently of manufacturer by checking CPUID bits. Using RDTSCP is the default in Linux to read TSC in program order when the instruction is available. https://github.com/torvalds/linux/blob/e22ce8eb631bdc47a4a4ea7ecf4e4ba499db4f93/arch/x86/include/asm/msr.h#L231 Change-Id: Ifa841843b9abb2816f8f0754a163ebf01385306d Reviewed-on: https://go-review.googlesource.com/c/go/+/344429 Reviewed-by: Keith Randall Trust: Martin Möhrmann Run-TryBot: Martin Möhrmann TryBot-Result: Go Bot