This CL removes the GOEXPERIMENT=nounified knob, and any conditional
statements that depend on that knob. Further CLs to remove unreachable
code follow this one.
Updates #57410.
Change-Id: I39c147e1a83601c73f8316a001705778fee64a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/458615
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
ExampleWithDeadline and ExampleWithTimeout used an arbitrary 1-second
timeout for a “blocked” select case, which could fail if the test
goroutine happens to be descheduled for over a second, or perhaps if
an NTP synchronization happens to jump by a second at just the right
time.
Either case is plausible, especially on a heavily-loaded or slow
machine (as is often the case for builders for unusual ports).
Instead of an arbitrary timeout, use a “ready” channel that is never
actually ready.
Fixes#57594.
Change-Id: I9ff68f50b041a3382e7b267c28c5259e886a9d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/460999
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
The 1-second timeout on execution of this test is empirically too
short on some platforms. Rather than trying to tune the timeout, allow
the test to time out on its own (and dump goroutines) if it deadlocks.
Fixes#57993.
Fixes#57994.
Change-Id: I69ee86c75034469e4b4cd391b8dc5616b93468b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/463180
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Since this may add a large number of --export-dynamic-symbol options,
use a response file if the command line gets large.
Fixes#53579
Change-Id: Ic226bf372bf1e177a3dae886d1c48f4ce3569c0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/414654
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 460656
Reason for revert: This breaks s390x.
Change-Id: I8fada14fabc90593b8033ed11188c04963d2da75
Reviewed-on: https://go-review.googlesource.com/c/go/+/463475
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
When we're compiling a resultInArg0 op, we need to clobber the
register containing the input value. So we first make a register copy
of the input value. We can then clobber either of the two registers
the value is in and still have the original input value in a register
for future uses.
Before this CL, we always clobbered the original, not the copy.
But that's not always the right decision - if the original is already
in a specific register that it needs to be in later (typically, a
return value register), clobber the copy instead.
This optimization can remove a mov instruction. It saves 1376 bytes
of instructions in cmd/go.
Change-Id: I162870c84b9a180da6715bb24c296a902974fed3
Reviewed-on: https://go-review.googlesource.com/c/go/+/460656
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
When calling a c library function, you discover that an error has
occurred, typically by looking at the return value of the function. Only
after that can you use errno to figure out the cause of the error.
Nothing about cgo changes that story -- you still have to look at the
result before checking the error that represents errno. If not you can
get false errors if the function happens to leak a non-zero errno.
Fix testpty to check errors correctly.
Change-Id: Idb95f8dd6a8ed63f653190c2e722e742cf50542b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463397
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This code path is unreachable anyway, and it adds new uses of
Type.Pkg, which shouldn't be used anymore.
Mark Type.Pkg as deprecated while here.
Updates #57410.
Change-Id: I1eec1c8ed99207d58d0ba0c44822bbad29dc64f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/458575
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This also makes path/filepath.Walk more consistent between
Windows and POSIX platforms.
According to
https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12
symlinks in a path that includes a trailing slash must be resolved
before a function acts on that path.
POSIX defines an lstat function, whereas the Win32 API does not, so
Go's os.Lstat should follow the (defined) POSIX semantics instead of
doing something arbitrarily different.
CL 134195 added a test for the correct POSIX behavior when os.Lstat is
called on a symlink. However, the test turned out to be broken on Windows,
and when it was fixed (in CL 143578) it was fixed with different Lstat
behavior on Windows than on all other platforms that support symlinks.
In #50807 we are attempting to provide consistent symlink behavior for
cmd/go. This unnecessary platform difference, if left uncorrected,
will make that fix much more difficult.
CL 460595 reworked the implementation of Stat and Lstat on Windows,
and with the new implementation this fix is straightforward.
For #50807.
Updates #27225.
Change-Id: Ia28821aa4aab6cefa021da2d9b803506cdb2621b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463177
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
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 <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Update race_windows_amd64.syso to latest tsan (V3) runtime.
This version of the runtime depends on libsynchronization.a, so to
use this syso, you need to also be using a sufficiently up to date
version of GCC (notably GCC 5.1, installed on the Go windows builders
right now, does not include this library).
Updates #48231.
Updates #35006.
Fixes#49761.
Change-Id: Ia1e2b1d8fe7e2c99728150734935a2c522006caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/420197
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The various forkAndExecInChild implementations have comments
explaining that they pre-declare variables to force allocations
to occur before forking, but then later use ":=" declarations
for additional variables.
To make it clearer that those ":=" declarations do not allocate,
we move their declarations up to the predeclared blocks.
For #57208.
Change-Id: Ie8cb577fa7180b51b64d6dc398169053fdf8ea97
Reviewed-on: https://go-review.googlesource.com/c/go/+/456516
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This brings the exported field names on these GOARCHes
in line with the other supported linux platforms.
Fixes#57313.
Change-Id: I2107a7116ba60dc0c0a27f776318e3eb69e51682
Reviewed-on: https://go-review.googlesource.com/c/go/+/457557
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This helps simplify the noise when adding ppc codegen tests. ppc64x
is used in other places to indicate something which runs on either
endian.
This helps cleanup existing codegen tests which are mostly
identical between endian variants.
condmove tests are converted as an example.
Change-Id: I2b2d98a9a1859015f62db38d62d9d5d7593435b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/462895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Replace deprecated // +build lines by their respective //go:build line
counterpart. Also remove build constraints implied by file name or type.
Change-Id: I8d18cd40071ca28d7654da8f0d22841f43729ca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/460538
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
https://go.dev/cl/460543 stopped using the "expect" parameter in
bootstrapType, but we forgot to actually remove it.
While here, staticcheck correctly points out that we can use the copy
builtin to fill builtinIdToTypeSlice, now that it and idToType are an
array and slice respectively.
Change-Id: I48078415ab9bdd5633cf41f33ab4dc78eb30b48a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462301
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This has been investigated and explained on the issue tracker.
Fixes#54402.
Change-Id: I4d8b971faa810591983ad028b7db16411f3b3b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/461456
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
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 <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This will be generated by go code built for dynamic linking when
built with GOPPC64=power10 in a future change.
Change-Id: I9bd7ca6b2a65c360465e35ef12b10d3fa6d75745
Reviewed-on: https://go-review.googlesource.com/c/go/+/463015
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation does a float64 to int64 conversion in order to check whether the number is odd, however it does not check for overflows. If an overflow occurs, the result is implementation-defined and while it happens to work on amd64 and i386, it produces an incorrect result on arm64 and possibly other architectures.
This change fixes that and also avoids calling isOddInt altogether if the base is +0, because it's unnecessary.
(I was considering avoiding the extra check if runtime.GOARCH is "amd64" or "i386", but I can't see this pattern being used anywhere outside the tests. And having separate files with build tags just for isOddInt() seems like an overkill)
Fixes#57465
Change-Id: Ieb243796194412aa6b98fac05fd19766ca2413ef
GitHub-Last-Rev: 3bfbd85c4c
GitHub-Pull-Request: golang/go#57494
Reviewed-on: https://go-review.googlesource.com/c/go/+/459815
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Change-Id: I3e9f05d221990b1ae464545d6d8b2e22c35bca21
Reviewed-on: https://go-review.googlesource.com/c/go/+/463077
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit 3680b5e9c4.
Reason for revert: causes long compile times on certain functions. See issue #57959
Change-Id: Ie9e881ca8abbc79a46de2bfeaed0b9d6c416ed42
Reviewed-on: https://go-review.googlesource.com/c/go/+/463295
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The importcycles method has not been useful since April 2016 when a large code deletion was performed.
The compiler itself provides some protection against import cycles, and the linker does import cycle detection in linksetup -> postorder.
For #57400
Change-Id: I3095bdb3f16a82ba25681bf4a20ceaa3c9613921
GitHub-Last-Rev: 87a46153b1
GitHub-Pull-Request: golang/go#57462
Reviewed-on: https://go-review.googlesource.com/c/go/+/459475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
When -m=N (where N > 1) is in effect, include a note in the trace
output if a given function is considered "big" during inlining
analysis, since this causes the inliner to be less aggressive. If a
small change to a large function happens to nudge it over the large
function threshold, it can be confusing for developers, thus it's
probably worth including this info in the remark output.
Change-Id: Id31a1b76371ab1ef9265ba28a377f97b0247d0a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/460317
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL updates File.readdir() on windows so it uses
GetFileInformationByHandleEx with FILE_ID_BOTH_DIR_INFO
instead of Find* APIs. The former is more performant because
it allows us to buffer IO calls and reduces the number of system calls,
passing from 1 per file to 1 every ~100 files
(depending on the size of the file name and the size of the buffer).
This change improve performance of File.ReadDir by 20-30%.
name old time/op new time/op delta
ReadDir-12 562µs ±14% 385µs ± 9% -31.60% (p=0.000 n=9+9)
name old alloc/op new alloc/op delta
ReadDir-12 29.7kB ± 0% 29.5kB ± 0% -0.88% (p=0.000 n=8+10)
name old allocs/op new allocs/op delta
ReadDir-12 399 ± 0% 397 ± 0% -0.50% (p=0.000 n=10+10)
This change also speeds up calls to os.SameFile when using FileStats
returned from File.readdir(), as their file ID can be inferred while
reading the directory.
Change-Id: Id56a338ee66c39656b564105cac131099218fb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/452995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL removes badsignal2 function, as it is unused on Windows.
badsignal2 was originally intended to abort the process when
an exception was raised on a non-Go thread, following the same approach
as Linux and others.
Since it was added, back on https://golang.org/cl/5797068, it has caused
several issues on Windows, see #8224 and #50877. That's because we can't
know wether the signal is bad or not, as our trap might not be at the
end of the exception handler chain.
To fix those issues, https://golang.org/cl/104200046 and CL 442896
stopped calling badsignal2, and CL 458135 removed one last incorrect
call on amd64 and 386.
Change-Id: I5bd31ee2672118ae0f1a2c8b46a1bb0f4893a011
Reviewed-on: https://go-review.googlesource.com/c/go/+/463116
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL factors out part of the Windows sigtramp implementation, which
was duplicated in all four architectures. The new common code is
implemented in Go rather than in assembly, which will make Windows
error handling easier to reason and maintain.
While here, implement the control flow guard workaround on
windows/386, which almost comes for free.
Change-Id: I0bf38c28c54793225126e161bd95527a62de05e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/458135
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This CL updates TestVectoredHandlerDontCrashOnLibrary so it can run on
windows/386 and windows/arm64. It still can't run on windows/arm as
it does not support c-shared buildmode (see #43800).
Change-Id: Id1577687e165e77d27633c632634ecf86e6e9d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/463117
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
EvalSymlinks calls Clean twice, one in walkSymlinks and another in
toNorm. The later is not necessary, as toNorm is only called by
EvalSymlinks and just after walkSymlinks cleans the path without any
path manipulation in between.
Change-Id: Ibdb782c7eed59468f0ebb913e98d2a7db0df010d
Reviewed-on: https://go-review.googlesource.com/c/go/+/454615
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Add error check when call `r.parseObject` in `parseArchive`.
Change-Id: Ib1739f25941262593cf63837e272b6ee896d8613
GitHub-Last-Rev: 5a17f9aa2c
GitHub-Pull-Request: golang/go#57624
Reviewed-on: https://go-review.googlesource.com/c/go/+/460755
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Prior to this change (as of CL 143578), our stat function attempted to
resolve all reparse points as if they were symlinks.
This results in an additional call to CreateFile when statting a
symlink file: we use CreateFile once to obtain the reparse tag and
check whether the file is actually a symlink, and if it is we call
CreateFile again without FILE_FLAG_OPEN_REPARSE_POINT to stat the link
target. Fortunately, since symlinks are rare on Windows that overhead
shouldn't be a big deal in practice.
Fixes#42919.
Change-Id: If453930c6e98040cd6525ac4aea60a84498c9579
Reviewed-on: https://go-review.googlesource.com/c/go/+/460595
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This CL avoids allocating in utf16.Decode for code point sequences
with less than 64 elements. It does so by splitting the function in two,
one that can be inlined that preallocates a buffer and the other that
does the heavy-lifting.
The mid-stack inliner will allocate the buffer in the caller stack,
and in many cases this will be enough to avoid the allocation.
unicode/utf16 benchmarks:
name old time/op new time/op delta
DecodeValidASCII-12 60.1ns ± 3% 16.0ns ±20% -73.40% (p=0.000 n=8+10)
DecodeValidJapaneseChars-12 61.3ns ±10% 14.9ns ±39% -75.71% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
DecodeValidASCII-12 48.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10)
DecodeValidJapaneseChars-12 48.0B ± 0% 0.0B -100.00% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
DecodeValidASCII-12 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
DecodeValidJapaneseChars-12 1.00 ± 0% 0.00 -100.00% (p=0.000 n=10+10)
I've also benchmarked os.File.ReadDir with this change applied
to demonstrate that it does make a difference in the caller site, in this
case via syscall.UTF16ToString:
name old time/op new time/op delta
ReadDir-12 592µs ± 8% 620µs ±16% ~ (p=0.280 n=10+10)
name old alloc/op new alloc/op delta
ReadDir-12 30.4kB ± 0% 22.4kB ± 0% -26.10% (p=0.000 n=8+10)
name old allocs/op new allocs/op delta
ReadDir-12 402 ± 0% 272 ± 0% -32.34% (p=0.000 n=10+10)
Change-Id: I65cf5caa3fd3b3a466c0ed837a50a96e975bbe6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/453415
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
This CL redesign how we get the TLS pointer on windows/i386.
It applies the same changes as done in CL 431775 for windows/amd64.
We were previously reading it from the [TEB] arbitrary data slot,
located at 0x14(FS), which can only hold 1 TLS pointer.
With this CL, we will read the TLS pointer from the TEB TLS slot array,
located at 0xE10(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: 0xE10 + index*4.
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(FS), AX
Notice that this approach will now be implemented in all the supported
windows arches.
[TEB]: https://en.wikipedia.org/wiki/Win32_Thread_Information_Block
[TlsAlloc]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc
Change-Id: If4550b0d44694ee6480d4093b851f4991a088b32
Reviewed-on: https://go-review.googlesource.com/c/go/+/454675
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Previously TryBot-tested with bucket bits = 4.
Also tested locally with bucket bits = 5.
This makes it much easier to change the size of map
buckets, and hopefully provides pointers to all the
code that in some way depends on details of map layout.
Change-Id: I9f6669d1eadd02f182d0bc3f959dc5f385fa1683
Reviewed-on: https://go-review.googlesource.com/c/go/+/462115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Change-Id: Ibffe46bad7d30df9380ba18d49eeb6782406a1aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/463115
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
If OpArgIntReg is incorrectly scheduled, that causes it to be spilled
incorrectly, which causes the argument to not be considered live
at the start of the function.
This is the test for CL 462858
Add a brief mention of why CL 462858 is needed in the scheduling code.
Change-Id: Id199456f88d9ee5ca46d7b0353a3c2049709880e
Reviewed-on: https://go-review.googlesource.com/c/go/+/462899
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Sort variables before display so that when there are multiple variables
to report, they are in a consistent order.
Otherwise they are ordered in the order they appear in the fn.Dcl list,
which can vary. Particularly, they vary depending on regabi.
Change-Id: I0db380f7cbe6911e87177503a4c3b39851ff1b5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462898
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
If the local network mangles invalid DNS queries, that is not a Go problem.
Change-Id: I54db392532eed988bca81b70a98cd6d11766af89
Reviewed-on: https://go-review.googlesource.com/c/go/+/461275
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
