aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/asm_386.s
AgeCommit message (Collapse)Author
2021-04-30runtime: switch openbsd/386 to pthreadsJoel Sing
This switches openbsd/386 to thread creation via pthreads, rather than doing direct system calls. Update #36435 Change-Id: I000a815fc0edd0272c3285954f3f007229bc60a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/250577 Trust: Joel Sing <joel@sing.id.au> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-04-21cmd/compile: allow conversion from slice to array ptrJosh Bleecher Snyder
Panic if the slice is too short. Updates #395 Change-Id: I90f4bff2da5d8f3148ba06d2482084f32b25c29a Reviewed-on: https://go-review.googlesource.com/c/go/+/301650 Trust: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2021-02-19runtime: fix spurious stack overflow detectionRuss Cox
The regabi builders are unhappy about badctxt calling throw calling systemstack calling gosave_systemstack_switch calling badctxt, all nosplit, repeating. This wouldn't actually happen since after one systemstack we'd end up on the system stack and the next one wouldn't call gosave_systemstack_switch at all. The badctxt call itself is in a very unlikely assertion failure inside gosave_systemstack_switch. Keep the assertion check but call runtime.abort instead on failure, breaking the detected (but not real) cycle. Change-Id: Iaf5c0fc065783b8c1c6d0f62d848f023a0714b96 Reviewed-on: https://go-review.googlesource.com/c/go/+/294069 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: use TOPFRAME to identify top-of-frame functionsRuss Cox
No change to actual runtime, but helps reduce the laundry list of functions. mcall, morestack, and asmcgocall are not actually top-of-frame, so those need more attention in follow-up CLs. mstart moved to assembly so that it can be marked TOPFRAME. Since TOPFRAME also tells DWARF consumers not to unwind this way, this change should also improve debuggers a marginal amount. This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. This CL is, however, not windows/arm64-specific. It is cleanup meant to make the port (and future ports) easier. Change-Id: If1e0d46ca973de5e46b62948d076f675f285b5d9 Reviewed-on: https://go-review.googlesource.com/c/go/+/288802 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: remove unnecessary writes to gp.sched.gRuss Cox
A g's sched.g is set in newproc1: newg.sched.g = guintptr(unsafe.Pointer(newg)) After that, it never changes. Yet lots of assembly code does "g.sched.g = g" unnecessarily. Remove all those lines to avoid confusion about whether it ever changes. Also, split gogo into two functions, one that does the nil g check and a second that does the actual switch. This way, if the nil g check fails, we get a stack trace showing the call stack that led to the failure. (The SP write would otherwise cause the stack trace to abort.) Also restore the proper nil g check in a handful of assembly functions. (There is little point in checking for nil g *after* installing it as the real g.) Change-Id: I22866b093f901f765de1d074e36eeec10366abfb Reviewed-on: https://go-review.googlesource.com/c/go/+/292109 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: unify asmcgocall and systemstack traceback setupRuss Cox
Both asmcgocall and systemstack need to save the calling Go code's context for use by traceback, but they do it differently. Systemstack's appraoch is better, because it doesn't require a special case in traceback. So make them both use that. While we are here, the fake mstart caller in systemstack is no longer needed and can be removed. (traceback knows to stop in systemstack because of the writes to SP.) Also remove the fake mstarts in sys_windows_*.s. And while we are there, fix the control flow guard code in sys_windows_arm.s. The current code is using pointers to a stack frame that technically is gone once we hit the RET instruction. Clearly it's working OK, but better not to depend on data below SP being preserved, even for just a few instructions. Store the value we need in other registers instead. (This code is only used for pushing a sigpanic call, which does not actually return to the site of the fault and therefore doesn't need to preserve any of the registers.) This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. This CL is, however, not windows/arm64-specific. It is cleanup meant to make the port (and future ports) easier. Change-Id: Id1e3ef5e54f7ad786e4b87043f2626eba7c3bbd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/288799 Trust: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2021-02-19runtime: clean up system calls during cgo callback initRuss Cox
During a cgocallback, the runtime calls needm to get an m. The calls made during needm cannot themselves assume that there is an m or a g (which is attached to the m). In the old days of making direct system calls, the only thing you had to do for such functions was mark them //go:nosplit, to avoid the use of g in the stack split prologue. But now, on operating systems that make system calls through shared libraries and use code that saves state in the g or m before doing so, it's not safe to assume g exists. In fact, it is not even safe to call getg(), because it might fault deferencing the TLS storage to find the g pointer (that storage may not be initialized yet, at least on Windows, and perhaps on other systems in the future). The specific routines that are problematic are usleep and osyield, which are called during lock contention in lockextra, called from needm. All this is rather subtle and hidden, so in addition to fixing the problem on Windows, this CL makes the fact of not running on a g much clearer by introducing variants usleep_no_g and osyield_no_g whose names should make clear that there is no g. And then we can remove the various sketchy getg() == nil checks in the existing routines. As part of this cleanup, this CL also deletes onosstack on Windows. onosstack is from back when the runtime was implemented in C. It predates systemstack but does essentially the same thing. Instead of having two different copies of this code, we can use systemstack consistently. This way we need not port onosstack to each architecture. This CL is part of a stack adding windows/arm64 support (#36439), intended to land in the Go 1.17 cycle. This CL is, however, not windows/arm64-specific. It is cleanup meant to make the port (and future ports) easier. Change-Id: I3352de1fd0a3c26267c6e209063e6e86abd26187 Reviewed-on: https://go-review.googlesource.com/c/go/+/288793 Trust: Russ Cox <rsc@golang.org> Trust: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
2021-02-16[dev.regabi] reflect: support for register ABI on amd64 for reflect.(Value).CallMichael Anthony Knyszek
This change adds support for the new register ABI on amd64 to reflect.(Value).Call. If internal/abi's register counts are non-zero, reflect will try to set up arguments in registers on the Call path. Note that because the register ABI becomes ABI0 with zero registers available, this should keep working as it did before. This change does not add any tests for the register ABI case because there's no way to do so at the moment. For #40724. Change-Id: I8aa089a5aa5a31b72e56b3d9388dd3f82203985b Reviewed-on: https://go-review.googlesource.com/c/go/+/272568 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2021-02-05[dev.regabi] runtime: delete gosave functionCherry Zhang
The runtime.gosave function is not used anywhere. Delete. Note: there is also a gosave<> function, which is actually used and not deleted. Change-Id: I64149a7afdd217de26d1e6396233f2becfad7153 Reviewed-on: https://go-review.googlesource.com/c/go/+/289719 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2020-10-26runtime: tidy cgocallbackAustin Clements
On amd64 and 386, we have a very roundabout way of remembering that we need to dropm on return that currently involves saving a zero to needm's argument slot and later bringing it back. Just store the zero. This also makes amd64 and 386 more consistent with cgocallback on all other platforms: rather than saving the old M to the G stack, they now save it to a named slot on the G0 stack. The needm function no longer needs a dummy argument to get the SP, so we drop that. Change-Id: I7e84bb4a5ff9552de70dcf41d8accf02310535e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/263268 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-10-26runtime,cmd/cgo: simplify C -> Go call pathAustin Clements
This redesigns the way calls work from C to exported Go functions. It removes several steps from the call path, makes cmd/cgo no longer sensitive to the Go calling convention, and eliminates the use of reflectcall from cgo. In order to avoid generating a large amount of FFI glue between the C and Go ABIs, the cgo tool has long depended on generating a C function that marshals the arguments into a struct, and then the actual ABI switch happens in functions with fixed signatures that simply take a pointer to this struct. In a way, this CL simply pushes this idea further. Currently, the cgo tool generates this argument struct in the exact layout of the Go stack frame and depends on reflectcall to unpack it into the appropriate Go call (even though it's actually reflectcall'ing a function generated by cgo). In this CL, we decouple this struct from the Go stack layout. Instead, cgo generates a Go function that takes the struct, unpacks it, and calls the exported function. Since this generated function has a generic signature (like the rest of the call path), we don't need reflectcall and can instead depend on the Go compiler itself to implement the call to the exported Go function. One complication is that syscall.NewCallback on Windows, which converts a Go function into a C function pointer, depends on cgocallback's current dynamic calling approach since the signatures of the callbacks aren't known statically. For this specific case, we continue to depend on reflectcall. Really, the current approach makes some overly simplistic assumptions about translating the C ABI to the Go ABI. Now we're at least in a much better position to do a proper ABI translation. For comparison, the current cgo call path looks like: GoF (generated C function) -> crosscall2 (in cgo/asm_*.s) -> _cgoexp_GoF (generated Go function) -> cgocallback (in asm_*.s) -> cgocallback_gofunc (in asm_*.s) -> cgocallbackg (in cgocall.go) -> cgocallbackg1 (in cgocall.go) -> reflectcall (in asm_*.s) -> _cgoexpwrap_GoF (generated Go function) -> p.GoF Now the call path looks like: GoF (generated C function) -> crosscall2 (in cgo/asm_*.s) -> cgocallback (in asm_*.s) -> cgocallbackg (in cgocall.go) -> cgocallbackg1 (in cgocall.go) -> _cgoexp_GoF (generated Go function) -> p.GoF Notably: 1. We combine _cgoexp_GoF and _cgoexpwrap_GoF and move the combined operation to the end of the sequence. This combined function also handles reflectcall's previous role. 2. We combined cgocallback and cgocallback_gofunc since the only purpose of having both was to convert a raw PC into a Go function value. We instead construct the Go function value in cgocallbackg1. 3. cgocallbackg1 no longer reaches backwards through the stack to get the arguments to cgocallback_gofunc. Instead, we just pass the arguments down. 4. Currently, we need an explicit msanwrite to mark the results struct as written because reflectcall doesn't do this. Now, the results are written by regular Go assignments, so the Go compiler generates the necessary MSAN annotations. This also means we no longer need to track the size of the arguments frame. Updates #40724, since now we don't need to teach cgo about the register ABI or change how it uses reflectcall. Change-Id: I7840489a2597962aeb670e0c1798a16a7359c94f Reviewed-on: https://go-review.googlesource.com/c/go/+/258938 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2020-04-08all: remove scattered remnants of darwin/386Austin Clements
This removes all conditions and conditional code (that I could find) that depended on darwin/386. Fixes #37610. Change-Id: I630d9ea13613fb7c0bcdb981e8367facff250ba0 Reviewed-on: https://go-review.googlesource.com/c/go/+/227582 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-10-09all: remove the nacl port (part 1)Brad Fitzpatrick
You were a useful port and you've served your purpose. Thanks for all the play. A subsequent CL will remove amd64p32 (including assembly files and toolchain bits) and remaining bits. The amd64p32 removal will be separated into its own CL in case we want to support the Linux x32 ABI in the future and want our old amd64p32 support as a starting point. Updates #30439 Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd Reviewed-on: https://go-review.googlesource.com/c/go/+/199499 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-29runtime: switch default order of hashing algorithmsKeith Randall
Currently the standard hasher is memhash, which checks whether aes instructions are available, and if so redirects to aeshash. With this CL, we call aeshash directly, which then redirects to the fallback hash if aes instructions are not available. This reduces the overhead for the hash function in the common case, as it requires just one call instead of two. On architectures which have no assembly hasher, it's a single jump slower. Thanks to Martin for this idea. name old time/op new time/op delta BigKeyMap-4 22.6ns ± 1% 21.1ns ± 2% -6.55% (p=0.000 n=9+10) Change-Id: Ib7ca77b63d28222eb0189bc3d7130531949d853c Reviewed-on: https://go-review.googlesource.com/c/go/+/190998 Reviewed-by: Martin Möhrmann <moehrmann@google.com>
2019-06-06runtime: fix scattered non-tab indentation in assemblyRuss Cox
Change-Id: I6940a4c747f2da871263afa6a4e3386395d5cf54 Reviewed-on: https://go-review.googlesource.com/c/go/+/180839 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-05-09runtime: fix vet complaints for linux/386Russ Cox
Working toward making the tree vet-safe instead of having so many exceptions in cmd/vet/all/whitelist. This CL makes "GOOS=linux GOARCH=386 go vet -unsafeptr=false runtime" happy, while keeping "GO_BUILDER_NAME=misc-vetall go tool dist test" happy too. For #31916. Change-Id: I3e5586a7ff6e359357350d0602c2259493280ded Reviewed-on: https://go-review.googlesource.com/c/go/+/176099 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2019-04-10runtime: correct the TLS base offset on AndroidElias Naur
CL 170955 set tlsg to the Android Q free TLS slot offset in the linker data (16 on amd64, 8 on 386), offsetting all TLS relative access. We need the 0'th slot (TLS_SLOT_SELF) at initialization, so compensate with a corresponding negative offset. Fixes the android/386 and android/amd64 builders broken by CL 170955. Change-Id: I9882088c0c8bc6a777d2aabc9404cb76f02b6cea Reviewed-on: https://go-review.googlesource.com/c/go/+/170956 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-04-08runtime,runtime/cgo: set up TLS storage for Android Q without cgoElias Naur
Android Q frees a static TLS slot for us to use. Use the offset of that slot as the default for our TLS offset. As a result, runtime/cgo is no more a requirement for Android Q and newer. Updates #31343 Updates #29674 Change-Id: I759049b2e2865bd3d4fdc05a8cfc6db8b0da1f5d Reviewed-on: https://go-review.googlesource.com/c/go/+/170955 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-03-29cmd/link/ld,cmd/internal/obj,runtime: make the Android TLS offset dynamicElias Naur
We're going to need a different TLS offset for Android Q, so the static offsets used for 386 and amd64 are no longer viable on Android. Introduce runtime·tls_g and use that for indexing into TLS storage. As an added benefit, we can then merge the TLS setup code for all android GOARCHs. While we're at it, remove a bunch of android special cases no longer needed. Updates #29674 Updates #29249 (perhaps fixes it) Change-Id: I77c7385aec7de8f1f6a4da7c9c79999157e39572 Reviewed-on: https://go-review.googlesource.com/c/go/+/169817 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-03-18cmd/compile,runtime: provide index information on bounds check failureKeith Randall
A few examples (for accessing a slice of length 3): s[-1] runtime error: index out of range [-1] s[3] runtime error: index out of range [3] with length 3 s[-1:0] runtime error: slice bounds out of range [-1:] s[3:0] runtime error: slice bounds out of range [3:0] s[3:-1] runtime error: slice bounds out of range [:-1] s[3:4] runtime error: slice bounds out of range [:4] with capacity 3 s[0:3:4] runtime error: slice bounds out of range [::4] with capacity 3 Note that in cases where there are multiple things wrong with the indexes (e.g. s[3:-1]), we report one of those errors kind of arbitrarily, currently the rightmost one. An exhaustive set of examples is in issue30116[u].out in the CL. The message text has the same prefix as the old message text. That leads to slightly awkward phrasing but hopefully minimizes the chance that code depending on the error text will break. Increases the size of the go binary by 0.5% (amd64). The panic functions take arguments in registers in order to keep the size of the compiled code as small as possible. Fixes #30116 Change-Id: Idb99a827b7888822ca34c240eca87b7e44a04fdd Reviewed-on: https://go-review.googlesource.com/c/go/+/161477 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
2019-03-14runtime: simplify constant strings in asmJosh Bleecher Snyder
As of CL 163747, we can write arbitrary length strings in assembly DATA instructions. Make use of it here to improve readability. Change-Id: I556279ca893f527874e3b26112c43573834ccd9c Reviewed-on: https://go-review.googlesource.com/c/go/+/167386 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-11-12runtime, reflect: access runtime.reflectcall directlyAustin Clements
Currently, package runtime contains the definition of reflect.call, even though it's just a jump to runtime.reflectcall. This "push" symbol is confusing, since it's not clear where the definition of reflect.call comes from when you're in the reflect package. Replace this with a "pull" symbol: the runtime now defines only runtime.reflectcall and package reflect uses a go:linkname to access this symbol directly. This makes it clear where reflect.call is coming from without any spooky action at a distance and eliminates all of the definitions of reflect.call in the runtime. Change-Id: I3ec73cd394efe9df8d3061a57c73aece2e7048dd Reviewed-on: https://go-review.googlesource.com/c/148657 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-10-03all: this big patch remove whitespace from assembly filesZhou Peng
Don't worry, this patch just remove trailing whitespace from assembly files, and does not touch any logical changes. Change-Id: Ia724ac0b1abf8bc1e41454bdc79289ef317c165d Reviewed-on: https://go-review.googlesource.com/c/113595 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-24all: align cpu feature variable offset namingMartin Möhrmann
Add an "offset_" prefix to all cpu feature variable offset constants to signify that they are not boolean cpu feature variables. Remove _ from offset constant names. Change-Id: I6e22a79ebcbe6e2ae54c4ac8764f9260bb3223ff Reviewed-on: https://go-review.googlesource.com/131215 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-24runtime: use internal/cpu variables in assembler codeMartin Möhrmann
Using internal/cpu variables has the benefit of avoiding false sharing (as those are padded) and allows memory and cache usage for these variables to be shared by multiple packages. Change-Id: I2bf68d03091bf52b466cf689230d5d25d5950037 Reviewed-on: https://go-review.googlesource.com/126599 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-05-25runtime: remove duplicate cpu feature detection on x86Martin Möhrmann
This also allows the GODEBUGCPU options to change the support_* runtime cpu feature variable values. Change-Id: I884c5f03993afc7e3344ff2fd471a2c6cfde43d4 Reviewed-on: https://go-review.googlesource.com/114615 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-05-20runtime: use libc for nanotime on DarwinKeith Randall
Use mach_absolute_time and mach_timebase_info to get nanosecond-level timing information from libc on Darwin. The conversion code from Apple's arbitrary time unit to nanoseconds is really annoying. It would be nice if we could replace the internal runtime "time" with arbitrary units and put the conversion to nanoseconds only in the places that really need it (so it isn't in every nanotime call). It's especially annoying because numer==denom==1 for all the machines I tried. Makes it hard to test the conversion code :( Update #17490 Change-Id: I6c5d602a802f5c24e35184e33d5e8194aa7afa86 Reviewed-on: https://go-review.googlesource.com/110655 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-05-19runtime: fix darwin 386/amd64 stack switchesKeith Randall
A few libc_ calls were missing stack switches. Unfortunately, adding the stack switches revealed a deeper problem. systemstack() is fundamentally flawed because when you do systemstack(func() { ... }) There's no way to mark the anonymous function as nosplit. At first I thought it didn't matter, as that function runs on the g0 stack. But nosplit is still required, because some syscalls are done when stack bounds are not set up correctly (e.g. in a signal handler, which runs on the g0 stack, but g is still pointing at the g stack). Instead use asmcgocall and funcPC, so we can be nosplit all the way down. Mid-stack inlining now pushes darwin over the nosplit limit also. Leaving that as a TODO. Update #23168 This might fix the cause of occasional darwin hangs. Update #25181 Update #17490 Change-Id: If9c3ef052822c7679f5a1dd192443f714483327e Reviewed-on: https://go-review.googlesource.com/111258 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-05-01runtime: convert exit to use pthread library on DarwinKeith Randall
Now we no longer need to mess with TLS on Darwin 386/amd64, we always rely on the pthread library to set it up. We now just use one entry in the TLS for the G. Return from mstart to let the pthread library clean up the OS thread. Change-Id: Iccf58049d545515d9b1d090b161f420e40ffd244 Reviewed-on: https://go-review.googlesource.com/110215 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-04-15runtime: use internal/cpu.X86.HasAVX2 instead of support_avx2Tobias Klauser
After CL 104636 cpu.X86.HasAVX is set early enough that it can be used in runtime·memclrNoHeapPointers. Add an offset to use in assembly and replace the only occurence of support_avx2. Change-Id: Icada62efeb3e24d71251d55623a8a8602364c9a8 Reviewed-on: https://go-review.googlesource.com/106595 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
2018-04-11runtime: use internal/cpu instead of support_avxTobias Klauser
After CL 104636 cpu.X86.HasAVX is set early enough that it can be used to determine useAVXmemmove. Use it and remove support_avx. Change-Id: Ib7a627bede2bf96c92362507e742bd833cb42a74 Reviewed-on: https://go-review.googlesource.com/106235 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-04-10runtime: use internal/cpu in alginitMeng Zhuo
After CL 104636 the feature flags in internal/cpu are initialized before alginit and can now be used for aeshash feature detection. Also remove now unused runtime variables: x86: support_ssse3 support_sse42 support_aes arm64: support_aes Change-Id: I2f64198d91750eaf3c6cf2aac6e9e17615811ec8 Reviewed-on: https://go-review.googlesource.com/106015 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-04-10runtime: remove support_bmi{1,2}Tobias Klauser
The code reading these variables was removed in CL 41476. They are only set but never read now, so remove them. Change-Id: I6b0b8d813e9a3ec2a13586ff92746e00ad1b5bf0 Reviewed-on: https://go-review.googlesource.com/106095 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-03-21runtime,sync/atomic: replace asm BYTEs with insts for x86isharipo
For each replacement, test case is added to new 386enc.s file with exception of EMMS, SYSENTER, MFENCE and LFENCE as they are already covered in amd64enc.s (same on amd64 and 386). The replacement became less obvious after go vet suggested changes Before: BYTE $0x0f; BYTE $0x7f; BYTE $0x44; BYTE $0x24; BYTE $0x08 Changed to MOVQ (this form is being tested): MOVQ M0, 8(SP) Refactored to FP-relative access (go vet advice): MOVQ M0, val+4(FP) Change-Id: I56b87cf3371b6ad81ad0cd9db2033aee407b5818 Reviewed-on: https://go-review.googlesource.com/101475 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
2018-03-08runtime: call abort instead of raw INT $3 or bad MOVAustin Clements
Everything except for amd64, amd64p32, and 386 currently defines and uses an abort function. This CL makes these match. The next CL will recognize the abort function to make this more useful. Change-Id: I7c155871ea48919a9220417df0630005b444f488 Reviewed-on: https://go-review.googlesource.com/93660 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-08runtime: make throw safer to callAustin Clements
Currently, throw may grow the stack, which means whenever we call it from a context where it's not safe to grow the stack, we first have to switch to the system stack. This is pretty easy to get wrong. Fix this by making throw switch to the system stack so it doesn't grow the stack and is hence safe to call without a system stack switch at the call site. The only thing this complicates is badsystemstack itself, which would now go into an infinite loop before printing anything (previously it would also go into an infinite loop, but would at least print the error first). Fix this by making badsystemstack do a direct write and then crash hard. Change-Id: Ic5b4a610df265e47962dcfa341cabac03c31c049 Reviewed-on: https://go-review.googlesource.com/93659 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-03-04internal/bytealg: move compare functions to bytealgKeith Randall
Move bytes.Compare and runtime·cmpstring to bytealg. Update #19792 Change-Id: I139e6d7c59686bef7a3017e3dec99eba5fd10447 Reviewed-on: https://go-review.googlesource.com/98515 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-03-03internal/bytealg: move equal functions to bytealgKeith Randall
Move bytes.Equal, runtime.memequal, and runtime.memequal_varlen to the bytealg package. Update #19792 Change-Id: Ic4175e952936016ea0bda6c7c3dbb33afdc8e4ac Reviewed-on: https://go-review.googlesource.com/98355 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-03-02internal/bytealg: move IndexByte asssembly to the new bytealg packageKeith Randall
Move the IndexByte function from the runtime to a new bytealg package. The new package will eventually hold all the optimized assembly for groveling through byte slices and strings. It seems a better home for this code than randomly keeping it in runtime. Once this is in, the next step is to move the other functions (Compare, Equal, ...). Update #19792 This change seems complicated enough that we might just declare "not worth it" and abandon. Opinions welcome. The core assembly is all unchanged, except minor modifications where the code reads cpu feature bits. The wrapper functions have been cleaned up as they are now actually checked by vet. Change-Id: I9fa75bee5d85db3a65b3fd3b7997e60367523796 Reviewed-on: https://go-review.googlesource.com/98016 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-02-27runtime: improve 386/amd64 systemstackJosh Bleecher Snyder
Minor improvements, noticed while investigating other things. Shorten the prologue. Make branch direction better for static branch prediction; the most common case by far is switching stacks (g==curg). Change-Id: Ib2211d3efecb60446355cda56194221ccb78057d Reviewed-on: https://go-review.googlesource.com/97377 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-02-13runtime: buffered write barrier for 386Austin Clements
Updates #22460. Change-Id: I3c8e90fd6bcda7e28911036591873d63665aaca7 Reviewed-on: https://go-review.googlesource.com/92696 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2017-10-30runtime: make systemstack tail call if already switchedAustin Clements
Currently systemstack always calls its argument, even if we're already on the system stack. Unfortunately, traceback with _TraceJump stops at the first systemstack it sees, which often cuts off runtime stacks early in profiles. Fix this by performing a tail call if we're already on the system stack. This eliminates it from the traceback entirely, so it won't stop prematurely (or all get mushed into a single node in the profile graph). Change-Id: Ibc69e8765e899f8d3806078517b8c7314da196f4 Reviewed-on: https://go-review.googlesource.com/74050 Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2017-10-29runtime: remove write barriers from newstack, gogoAustin Clements
Currently, newstack and gogo have write barriers for maintaining the context register saved in g.sched.ctxt. This is troublesome, because newstack can be called from go:nowritebarrierrec places that can't allow write barriers. It happens to be benign because g.sched.ctxt will always be nil on entry to newstack *and* it so happens the incoming ctxt will also always be nil in these contexts (I think/hope), but this is playing with fire. It's also desirable to mark newstack go:nowritebarrierrec to prevent any other, non-benign write barriers from creeping in, but we can't do that right now because of this one write barrier. Fix all of this by observing that g.sched.ctxt is really just a saved live pointer register. Hence, we can shade it when we scan g's stack and otherwise move it back and forth between the actual context register and g.sched.ctxt without write barriers. This means we can save it in morestack along with all of the other g.sched, eliminate the save from newstack along with its troublesome write barrier, and eliminate the shenanigans in gogo to invoke the write barrier when restoring it. Once we've done all of this, we can mark newstack go:nowritebarrierrec. Fixes #22385. For #22460. Change-Id: I43c24958e3f6785b53c1350e1e83c2844e0d1522 Reviewed-on: https://go-review.googlesource.com/72553 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2017-10-18runtime: align stack in 386 lib startup before calling C functionIan Lance Taylor
Fixes Darwin 386 build. It turns out that the Darwin pthread_create function saves the SSE registers, and therefore requires an aligned stack. This worked before https://golang.org/cl/70530 because the stack sizes were chosen to leave the stack aligned. Change-Id: I911a9e8dcde4e41e595d5ef9b9a1ca733e154de6 Reviewed-on: https://go-review.googlesource.com/71432 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-10-17runtime: unify 386 entry point codeIan Lance Taylor
Unify the 386 entry point code as much as possible. The main function could not be unified because on Windows 386 it is called _main. Putting main in asm_386.s caused multiple definition errors when using the external linker. Add the _lib entry point to various operating systems. A future CL will enable c-archive/c-shared mode for those targets. Fix _rt0_386_windows_lib_go--it was passing arguments as though it were amd64. Change-Id: Ic73f1c95cdbcbea87f633f4a29bbc218a5db4f58 Reviewed-on: https://go-review.googlesource.com/70530 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-09-22cmd/compile: add intrinsic for reading caller's pcDavid Chase
First step towards removing the mandatory argument for getcallerpc, which solves certain problems for the runtime. This might also slightly improve performance. Intrinsic enabled on 386, amd64, amd64p32, runtime asm implementation removed on those architectures. Now-superfluous argument remains in getcallerpc signature (for a future CL; non-386/amd64 asm funcs ignore it). Added getcallerpc to the "not a real function" test in dcl.go, that story is a little odd with respect to unexported functions but that is not this CL. Fixes #17327. Change-Id: I5df1ad91f27ee9ac1f0dd88fa48f1329d6306c3e Reviewed-on: https://go-review.googlesource.com/31851 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2017-08-22cmd/compile: replace eqstring with memequalMartin Möhrmann
eqstring is only called for strings with equal lengths. Instead of pushing a pointer and length for each argument string on the stack we can omit pushing one of the lengths on the stack. Changing eqstrings signature to eqstring(*uint8, *uint8, int) bool to implement the above optimization would make it very similar to the existing memequal(*any, *any, uintptr) bool function. Since string lengths are positive we can avoid code redundancy and use memequal instead of using eqstring with an optimized signature. go command binary size reduced by 4128 bytes on amd64. name old time/op new time/op delta CompareStringEqual 6.03ns ± 1% 5.71ns ± 1% -5.23% (p=0.000 n=19+18) CompareStringIdentical 2.88ns ± 1% 3.22ns ± 7% +11.86% (p=0.000 n=20+20) CompareStringSameLength 4.31ns ± 1% 4.01ns ± 1% -7.17% (p=0.000 n=19+19) CompareStringDifferentLength 0.29ns ± 2% 0.29ns ± 2% ~ (p=1.000 n=20+20) CompareStringBigUnaligned 64.3µs ± 2% 64.1µs ± 3% ~ (p=0.164 n=20+19) CompareStringBig 61.9µs ± 1% 61.6µs ± 2% -0.46% (p=0.033 n=20+19) Change-Id: Ice15f3b937c981f0d3bc8479a9ea0d10658ac8df Reviewed-on: https://go-review.googlesource.com/53650 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2017-08-11runtime, cmd/compile: add intrinsic getclosureptrCholerae Hu
Intrinsic enabled on all architectures, runtime asm implementation removed on all architectures. Fixes #21258 Change-Id: I2cb86d460b497c2f287a5b3df5c37fdb231c23a7 Reviewed-on: https://go-review.googlesource.com/53411 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: David Chase <drchase@google.com>
2017-08-08runtime: remove unused prefetch functionsMartin Möhrmann
The only non test user of the assembler prefetch functions is the heapBits.prefetch function which is itself unused. The runtime prefetch functions have no functionality on most platforms and are not inlineable since they are written in assembler. The function call overhead eliminates the performance gains that could be achieved with prefetching and would degrade performance for platforms where the functions are no-ops. If prefetch functions are needed back again later they can be improved by avoiding the function call overhead and implementing them as intrinsics. Change-Id: I52c553cf3607ffe09f0441c6e7a0a818cb21117d Reviewed-on: https://go-review.googlesource.com/44370 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-05-10runtime: remove unused cpuid_X variablesMartin Möhrmann
They are not exported and not used in the compiler or standard library. Change-Id: Ie1d210464f826742d282f12258ed1792cbd2d188 Reviewed-on: https://go-review.googlesource.com/43135 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>