| Age | Commit message (Collapse) | Author |
|---|
|
Rather than ad hoc setting up the universe, just initialize it
properly.
Change-Id: I18484b952321f55eb3e1e48fd383068a4ee75f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/345475
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
arithmetic expressions
This applies the following generic integer addition/subtraction transformations:
x - (x + y) = -y
(x - y) - x = -y
y + (x - y) = x
y + (z + (x - y) = x + z
There's over 40 unique functions matching in Go. Hits 2 funcs in the runtime itself:
runtime.stackfree()
runtime.runqdrain()
Go binary size reduced by 0.05% on Linux x86_64.
StackCopy bench (perflocked Cascade Lake x86):
name old time/op new time/op delta
StackCopyPtr-8 87.3ms ± 1% 86.9ms ± 0% -0.45% (p=0.000 n=20+20)
StackCopy-8 77.6ms ± 1% 77.0ms ± 0% -0.76% (p=0.000 n=20+20)
StackCopyNoCache-8 2.28ms ± 2% 2.26ms ± 2% -0.93% (p=0.008 n=19+20)
test/bench/go1 benchmarks (perflocked Cascade Lake x86):
name old time/op new time/op delta
BinaryTree17-8 1.88s ± 1% 1.88s ± 0% ~ (p=0.373 n=15+12)
Fannkuch11-8 2.31s ± 0% 2.35s ± 0% +1.52% (p=0.000 n=15+14)
FmtFprintfEmpty-8 26.6ns ± 0% 26.6ns ± 0% ~ (p=0.081 n=14+13)
FmtFprintfString-8 48.6ns ± 0% 50.0ns ± 0% +2.86% (p=0.000 n=15+14)
FmtFprintfInt-8 56.9ns ± 0% 54.8ns ± 0% -3.70% (p=0.000 n=15+15)
FmtFprintfIntInt-8 90.4ns ± 0% 88.8ns ± 0% -1.78% (p=0.000 n=15+15)
FmtFprintfPrefixedInt-8 104ns ± 0% 104ns ± 0% ~ (p=0.905 n=14+13)
FmtFprintfFloat-8 148ns ± 0% 144ns ± 0% -2.19% (p=0.000 n=14+15)
FmtManyArgs-8 389ns ± 0% 390ns ± 0% +0.35% (p=0.000 n=12+15)
GobDecode-8 3.90ms ± 1% 3.88ms ± 0% -0.49% (p=0.000 n=15+14)
GobEncode-8 2.73ms ± 0% 2.73ms ± 0% ~ (p=0.425 n=15+14)
Gzip-8 169ms ± 0% 168ms ± 0% -0.52% (p=0.000 n=13+13)
Gunzip-8 24.7ms ± 0% 24.8ms ± 0% +0.61% (p=0.000 n=15+15)
HTTPClientServer-8 60.5µs ± 6% 60.4µs ± 7% ~ (p=0.595 n=15+15)
JSONEncode-8 6.97ms ± 1% 6.93ms ± 0% -0.69% (p=0.000 n=14+14)
JSONDecode-8 31.2ms ± 1% 30.8ms ± 1% -1.27% (p=0.000 n=14+14)
Mandelbrot200-8 3.87ms ± 0% 3.87ms ± 0% ~ (p=0.652 n=15+14)
GoParse-8 2.65ms ± 2% 2.64ms ± 1% ~ (p=0.202 n=15+15)
RegexpMatchEasy0_32-8 45.1ns ± 0% 45.9ns ± 0% +1.68% (p=0.000 n=14+15)
RegexpMatchEasy0_1K-8 140ns ± 0% 139ns ± 0% -0.44% (p=0.000 n=15+14)
RegexpMatchEasy1_32-8 40.9ns ± 3% 40.5ns ± 0% -0.88% (p=0.000 n=15+13)
RegexpMatchEasy1_1K-8 215ns ± 1% 220ns ± 1% +2.27% (p=0.000 n=15+15)
RegexpMatchMedium_32-8 783ns ± 7% 738ns ± 0% ~ (p=0.361 n=15+15)
RegexpMatchMedium_1K-8 24.1µs ± 6% 23.4µs ± 6% -2.94% (p=0.004 n=15+15)
RegexpMatchHard_32-8 1.10µs ± 1% 1.09µs ± 1% -0.40% (p=0.006 n=15+14)
RegexpMatchHard_1K-8 33.0µs ± 0% 33.0µs ± 0% ~ (p=0.535 n=12+14)
Revcomp-8 354ms ± 0% 353ms ± 0% -0.23% (p=0.002 n=15+13)
Template-8 42.0ms ± 1% 41.8ms ± 2% -0.37% (p=0.023 n=14+15)
TimeParse-8 181ns ± 0% 180ns ± 1% -0.18% (p=0.014 n=12+13)
TimeFormat-8 240ns ± 0% 242ns ± 1% +0.69% (p=0.000 n=12+15)
[Geo mean] 35.2µs 35.1µs -0.43%
name old speed new speed delta
GobDecode-8 197MB/s ± 1% 198MB/s ± 0% +0.49% (p=0.000 n=15+14)
GobEncode-8 281MB/s ± 0% 281MB/s ± 0% ~ (p=0.419 n=15+14)
Gzip-8 115MB/s ± 0% 115MB/s ± 0% +0.52% (p=0.000 n=13+13)
Gunzip-8 786MB/s ± 0% 781MB/s ± 0% -0.60% (p=0.000 n=15+15)
JSONEncode-8 278MB/s ± 1% 280MB/s ± 0% +0.69% (p=0.000 n=14+14)
JSONDecode-8 62.3MB/s ± 1% 63.1MB/s ± 1% +1.29% (p=0.000 n=14+14)
GoParse-8 21.9MB/s ± 2% 22.0MB/s ± 1% ~ (p=0.205 n=15+15)
RegexpMatchEasy0_32-8 709MB/s ± 0% 697MB/s ± 0% -1.65% (p=0.000 n=14+15)
RegexpMatchEasy0_1K-8 7.34GB/s ± 0% 7.37GB/s ± 0% +0.43% (p=0.000 n=15+15)
RegexpMatchEasy1_32-8 783MB/s ± 2% 790MB/s ± 0% +0.88% (p=0.000 n=15+13)
RegexpMatchEasy1_1K-8 4.77GB/s ± 1% 4.66GB/s ± 1% -2.23% (p=0.000 n=15+15)
RegexpMatchMedium_32-8 41.0MB/s ± 7% 43.3MB/s ± 0% ~ (p=0.360 n=15+15)
RegexpMatchMedium_1K-8 42.5MB/s ± 6% 43.8MB/s ± 6% +3.07% (p=0.004 n=15+15)
RegexpMatchHard_32-8 29.2MB/s ± 1% 29.3MB/s ± 1% +0.41% (p=0.006 n=15+14)
RegexpMatchHard_1K-8 31.1MB/s ± 0% 31.1MB/s ± 0% ~ (p=0.495 n=12+14)
Revcomp-8 718MB/s ± 0% 720MB/s ± 0% +0.23% (p=0.002 n=15+13)
Template-8 46.3MB/s ± 1% 46.4MB/s ± 2% +0.38% (p=0.021 n=14+15)
[Geo mean] 205MB/s 206MB/s +0.57%
Change-Id: Ibd1afdf8b6c0b08087dcc3acd8f943637eb95ac0
Reviewed-on: https://go-review.googlesource.com/c/go/+/344930
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
|
|
Currently, write barriers aren't emitted for global addresses, but they
are emitted for addresses offset of global addresses.
This CL changes IsGlobalAddr to recognize offsets of global addresses
as globals too, removing write barriers for staticuint64s based
addresses. The logic added is the same as used in IsStackAddr.
Updates #37612
Change-Id: I537579f85b9ad02987d94f3ee0b4508b90097959
Reviewed-on: https://go-review.googlesource.com/c/go/+/342129
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
We can end up with this situation due to our equality tests being based on
'SEQZ (SUB x y)' - if x is a zero valued constant, 'SUB x y' can be converted
to 'NEG x'. When used with a branch the SEQZ can be absorbed, leading to
'BNEZ (NEG x)' where the NEG is redundant.
Removes around 1700 instructions from the go binary on riscv64.
Change-Id: I947a080d8bf7d2d6378ab114172e2342ce2c51db
Reviewed-on: https://go-review.googlesource.com/c/go/+/342850
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Convert BLT and BGE with a zero valued constant to BGTZ/BLTZ/BLEZ/BGEZ as
appropriate.
Removes over 4,500 instructions from the go binary on riscv64.
Change-Id: Icc266e968b126ba04863ec88529630a9dd44498b
Reviewed-on: https://go-review.googlesource.com/c/go/+/342849
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Also tweak comment for the arm64 case.
Change-Id: I073405bd2acf901dcaaf33a034a84b6a09dd4a83
Reviewed-on: https://go-review.googlesource.com/c/go/+/334869
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
According to RISCV instruction set manual v2.2 Sec 6.1
MULHU followed by MUL will be fused into one multiply by microarchitecture
name old time/op new time/op delta
MulUintptr/small 11.2ns ±24% 9.2ns ± 0% -17.54% (p=0.000 n=10+9)
MulUintptr/large 15.9ns ± 0% 10.9ns ± 0% -31.55% (p=0.000 n=8+8)
Change-Id: I3d152218f83948cbc5c576bda29dc86e9b4206ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/338753
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
|
|
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixes golang/go#41400
Fixes golang/go#43078
NOTE: This change also includes a fix (CL 341929) for a test that was
broken by the original CL. Commit message for the fix is below.
[dev.cmdgo] cmd/link: fix TestBuildForTvOS
This test was broken in CL 334732 on darwin.
The test invokes 'go build' with a CC containing the arguments
-framework CoreFoundation. Previously, the go command split CC on
whitespace, and inserted the arguments after the command line when
running CC directly. Those arguments weren't passed to cgo though,
so cgo ran CC without -framework CoreFoundation (or any of the other
flags).
In CL 334732, we pass CC through to cgo, and cgo splits arguments
using str.SplitQuotedFields. So -framework CoreFoundation actually
gets passed to the C compiler. It appears that -framework flags are
only meant to be used in linking operations, so when cgo invokes clang
with -E (run preprocessor only), clang emits an error that -framework
is unused.
This change fixes the test by moving -framework CoreFoundation out of
CC and into CGO_LDFLAGS.
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/341936
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Fixes #46186
Change-Id: Idb0674079f9484593e07cca172dfbb19be0e594d
GitHub-Last-Rev: 615fc5365510ff7a39af7569f05a0013b724d0c9
GitHub-Pull-Request: golang/go#46185
Reviewed-on: https://go-review.googlesource.com/c/go/+/320111
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: David Chase <drchase@google.com>
|
|
According to RISCV instruction set manual v2.2 Sec 6.1
MULHU followed by MUL will be fused into one multiply by microarchitecture
Benchstat on Hifive unmatched:
name old time/op new time/op delta
Hash8Bytes 245ns ± 3% 186ns ± 4% -23.99% (p=0.000 n=10+10)
Hash320Bytes 1.94µs ± 1% 1.31µs ± 1% -32.38% (p=0.000 n=9+10)
Hash1K 5.84µs ± 0% 3.84µs ± 0% -34.20% (p=0.000 n=10+9)
Hash8K 45.3µs ± 0% 29.4µs ± 0% -35.04% (p=0.000 n=10+10)
name old speed new speed delta
Hash8Bytes 32.7MB/s ± 3% 43.0MB/s ± 4% +31.61% (p=0.000 n=10+10)
Hash320Bytes 165MB/s ± 1% 244MB/s ± 1% +47.88% (p=0.000 n=9+10)
Hash1K 175MB/s ± 0% 266MB/s ± 0% +51.98% (p=0.000 n=10+9)
Hash8K 181MB/s ± 0% 279MB/s ± 0% +53.94% (p=0.000 n=10+10)
Change-Id: I3561495d02a4a0ad8578e9b9819bf0a4eaca5d12
Reviewed-on: https://go-review.googlesource.com/c/go/+/329970
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
|
|
CL 294430 made packages in std and cmd modules use Go 1.17 gofmt format,
adding //go:build lines. This change applies the same formatting to some
more packages that 'go fmt' missed (e.g., syscall/js, runtime/msan), and
everything else that is easy and safe to modify in bulk.
Consider the top-level test directory, testdata, and vendor directories
out of scope, since there are many files that don't follow strict gofmt
formatting, often for intentional and legitimate reasons (testing gofmt
itself, invalid Go programs that shouldn't crash the compiler, etc.).
That makes it easy and safe to gofmt -w the .go files that are found
with gofmt -l with aforementioned directories filtered out:
$ gofmt -l . 2>/dev/null | \
grep -v '^test/' | \
grep -v '/testdata/' | \
grep -v '/vendor/' | wc -l
51
None of the 51 files are generated. After this change, the same command
prints 0.
For #41184.
Change-Id: Ia96ee2a0f998d6a167d4473bcad17ad09bc1d86e
Reviewed-on: https://go-review.googlesource.com/c/go/+/341009
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Previously, softfloat mode does not work with register ABI, mainly
because the compiler doesn't know how to pass floating point
arguments and results. According to the ABI it should be passed in
FP registers, but there isn't any in softfloat mode.
This CL makes it work. When softfloat is used, we define the ABI
as having 0 floating point registers (because there aren't any).
The integer registers are unchanged. So floating point arguments
and results are passed in memory.
Another option is to pass (the bit representation of) floating
point values in integer registers. But this complicates things
because it'd need to reorder integer argument registers.
Change-Id: Ibecbeccb658c10a868fa7f2dcf75138f719cc809
Reviewed-on: https://go-review.googlesource.com/c/go/+/327274
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Conflicts:
- src/cmd/compile/internal/escape/escape.go
On master, CL 332230 changed the ">=" in HeapAllocReason to ">"; but
on dev.typeparams, CL 329989 moved HeapAllocReason into utils.go.
Merge List:
+ 2021-07-02 912f075047 net/http: mention socks5 support in proxy
+ 2021-07-02 287c5e8066 cmd/compile: fix stack growing algorithm
+ 2021-07-02 743f03eeb0 spec, unsafe: clarify unsafe.Slice docs
+ 2021-07-02 6125d0c426 cmd/dist: correct comment: SysProcAttri -> SysProcAttr
+ 2021-07-01 03761ede02 net: don't reject null mx records
+ 2021-07-01 877688c838 testing: add TB.Setenv
+ 2021-07-01 ef8ae82b37 cmd/compile: fix bug in dwarf-gen var location generation
+ 2021-07-01 770899f7e1 cmd/go: add a regression test for 'go mod vendor' path traversal
+ 2021-07-01 835d86a17e cmd/go: use path.Dir instead of filepath.Dir for package paths in 'go mod vendor'
+ 2021-07-01 eb437ba92c cmd/compile: make stack value size threshold comparisons consistent
+ 2021-07-01 9d65578b83 cmd/compile: fix typos in document
Change-Id: I08aa852441af0f070aa32dd2f99b6fa4e9d79cfa
|
|
This patch fixes a bug in the SSA back end's DWARF generation code
that determines variable locations / lifetimes.
The code in question was written to handle sequences of initial
pseudo-ops (zero width instructions such as OpPhi, OpArg, etc) in a
basic block, detecting these ops at the start of a block and then
treating the values specially when emitting ranges for the variables
in those values. The logic in this code wasn't quite correct, meaning
that a flag variable wasn't being set properly to record the presence
of a block of zero-width value-bearing ops, leading to incorrect or
missing DWARF locations for register params.
Also in this patch is a tweak to some sanity-checking code intended to
catch scheduling problems with OpArg/OpPhi etc. The checks need to
allow for the possibility of an Arg op scheduled after a spill of an
incoming register param inserted by the register allocator. Example:
b1:
v13 = ArgIntReg <int> {p1+16} [2] : CX
v14 = ArgIntReg <int> {p2+16} [5] : R8
v38 = ArgIntReg <int> {p3+16} [8] : R11
v35 = ArgIntReg <int> {p1+0} [0] : AX
v15 = StoreReg <int> v35 : .autotmp_4[int]
v40 = Arg <int> {p4} [16] : p4+16[int]
v1 = InitMem <mem>
v3 = SB <uintptr> : SB
v18 = CMPQ <flags> v14 v13
NE v18 → b3 b2 (unlikely) (18)
Here the register allocator has decided to spill v35, meaning that the
OpArg v40 is no longer going to be positioned prior to all other
non-zero-width ops; this is a valid scenario and needs to be handled
properly by the debug code.
Fixes #46425.
Change-Id: I239b3ad56a9c1b8ebf68af42e1f57308293ed7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/332269
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
This CL implements a few improvements to SSA devirtualization to make
it simpler and more general:
1. Change reflectdata.ITabAddr to now immediately generate the wrapper
functions and write out the itab symbol data. Previously, these were
each handled by separate phases later on.
2. Removes the hack in typecheck where we marked itabs that we
expected to need later. Instead, the calls to ITabAddr in walk now
handle generating the wrappers.
3. Changes the SSA interface call devirtualization algorithm to just
use the itab symbol data (namely, its relocations) to figure out what
pointer is available in memory at the given offset. This decouples it
somewhat from reflectdata.
Change-Id: I8fe06922af8f8a1e7c93f5aff2b60ff59b8e7114
Reviewed-on: https://go-review.googlesource.com/c/go/+/327871
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Always enable regabig on AMD64, which enables the G register and
the X15 zero register. Remove the fallback path.
Also remove the regabig GOEXPERIMENT. On AMD64 it is always
enabled (this CL). Other architectures already have a G register,
except for 386, where there are too few registers and it is
unlikely that we will reserve one. (If we really do, we can just
add a new experiment).
Change-Id: I229cac0060f48fe58c9fdaabd38d6fa16b8a0855
Reviewed-on: https://go-review.googlesource.com/c/go/+/327272
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Looks like CL 322850 didn't have the change to ARM64Ops.go
properly gofmt'ed.
Change-Id: I1a080bc13ea27b897fbb91f18ded754ce440994b
Reviewed-on: https://go-review.googlesource.com/c/go/+/324109
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
ARM64
Update the rule to match register-ABI version of the call for
inlining memmove.
Change-Id: Ic6da810e4d7ac391ffb766fcdc943985f0739624
Reviewed-on: https://go-review.googlesource.com/c/go/+/323930
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Now they take variable number of args.
Change-Id: I49c8bce9c3a403947eac03e397ae264a8f4fdd2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/323929
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Merge List:
+ 2021-06-01 272552275f A+C: update name
+ 2021-06-01 2bec019fb5 doc/go1.17: add release notes for register ABI
+ 2021-06-01 2e59cc5fb4 cmd/go: add [-src] to documentation
+ 2021-06-01 0b80cf1136 cmd/go: make 'go get' save sums for incidentally updated modules
+ 2021-05-30 3b770f2ccb go/types: don't declare 'comparable' when typeparams are disabled
+ 2021-05-30 1607c28172 go/types: unexport the GoVersion configuration option for Go 1.17
+ 2021-05-29 79bda65041 doc/go1.17: mention time.Layout
+ 2021-05-29 f6cc392d1d doc/go1.17: document text/template/parse.SkipFuncCheck
+ 2021-05-28 1419ca7cea doc/go1.17: mention new definitions of MSG_CMSG_CLOEXEC
+ 2021-05-28 6624771c83 doc/go1.17: mention testing.[TB].Setenv methods
+ 2021-05-28 bbda923592 doc/go1.17: mention new Windows SysProcAttr fields
+ 2021-05-28 6f58088bd8 doc/go1.17: document new go/build/BuildContext.ToolTags field
+ 2021-05-28 c295107708 doc/go1.17: mention new encoding/csv/Reader.FieldPos method
+ 2021-05-28 ccd9784edf doc/go1.17: document new debug/elf constant
+ 2021-05-28 3de3440fb9 go/ast: remove FuncDecl.IsMethod for Go 1.17
+ 2021-05-27 639acdc833 doc/go1.17: clarify that compress/lzw Reader and Writer types are new
+ 2021-05-27 193d514131 net/http: correct Client.Do doc about context cancelation
+ 2021-05-27 ab2ef4aaa7 doc/go1.17: document reflect changes
+ 2021-05-27 0ece95a0fe cmd/go: don't let 'go mod download' save sums for inconsistent requirements
+ 2021-05-27 cdcd02842d net: verify results from Lookup* are valid domain names
+ 2021-05-27 8bf5bf5173 cmd/compile: improve debug locations for partially live in-params
+ 2021-05-27 56af34f875 cmd/compile: place reg spills after OpArg{Int,Float}Reg ops
+ 2021-05-27 db66e9e15d cmd/link: accept Windows line-ending in TestTrampolineCgo
+ 2021-05-27 6b8c94b6c5 go/types: guard against check==nil in newNamed
+ 2021-05-27 fca7b8f3e6 Revert "net: verify results from Lookup* are valid domain names"
+ 2021-05-27 950fa11c4c net/http/httputil: always remove hop-by-hop headers
+ 2021-05-27 9bc52686da cmd/go,cmd/link: do not check for staleness in most tests
+ 2021-05-27 6ff0ae2aa4 crypto/elliptic: fix typo in p521Point type name
+ 2021-05-26 3075ffc93e os: deflake TestFdReadRace
+ 2021-05-26 a62c08734f src/os: revert accidentally submitted change
+ 2021-05-26 1d5298d46a doc/go1.17: document net/... changes
+ 2021-05-26 0fbecece98 doc/go1.17: document syscall changes
+ 2021-05-26 02beecb397 mime: document use of the Shared MIME-Info Database
+ 2021-05-26 a92460fd2f doc/go1.17: add release notes for runtime/metrics package
+ 2021-05-26 55aefbb268 doc/go1.17: mention enabling frame pointer on all ARM64
+ 2021-05-26 39da9ae513 go/types: ensure that Named.check is nilled out once it is expanded
+ 2021-05-26 bfd7798a6c runtime,cmd/link/internal/ld: fix typos
+ 2021-05-26 e4615ad74d math/big: move division into natdiv.go
+ 2021-05-26 d050238bb6 doc/go1.17: fix formatting for time changes
+ 2021-05-25 74242baa41 archive/zip: only preallocate File slice if reasonably sized
Change-Id: I8a02edee1a6889547c52aa28c53cf8250766ab2c
|
|
During DWARF debug location generation, as a preamble to the main data
flow analysis, examine the function entry block to look for in-params
arriving in registers that are partially or completely dead, and
insert new OpArg{Int,Float}Reg values for the dead or partially-dead
pieces. In addition, add entries to the f.NamedValues table for
incoming live register-resident params that don't already have
entries. This helps create better/saner DWARF location expressions for
params. Example:
func foo(s string, used int, notused int) int {
return len(s) + used
}
When optimization is complete for this function, the parameter
"notused" is completely dead, meaning that there is no entry for it in
the f.NamedValues table (which then means we don't emit a DWARF
variable location expression for it in the function enty block). In
addition, since only the length field of "s" is used, there is no
DWARF location expression for the other component of "s", leading to
degraded DWARF.
There are still problems/issues with DWARF location generation, but
this does improve things with respect to being able to print the
values of incoming parameters when stopped in the debugger at the
entry point of a function (when optimization is enabled).
Updates #40724.
Change-Id: I5bb5253648942f9fd33b081fe1a5a36208e75785
Reviewed-on: https://go-review.googlesource.com/c/go/+/322631
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Tweak the register allocator to maintain the invariant that
OpArg{Int,Float}Reg values are placed together at the start of the
entry block, before any other non-pseudo-op values. Without this
change, when the register allocator adds spills we can wind up with an
interleaving of OpArg*Reg and stores, which complicates debug location
analysis.
Updates #40724.
Change-Id: Icf30dd814a9e25263ecbea2e48feb840a6e7f2bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322630
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Now it will be used for functions marked go:registerparams.
test/abi tests are passing with it.
Change-Id: I5af37ae6b79a1064832a42c7ef5f2cc0b5b6a342
Reviewed-on: https://go-review.googlesource.com/c/go/+/322854
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Define the registers.
They are not really enabled for now. Otherwise the compiler will
start using them for go:registerparams functions and it is not
fully working. Some test will fail.
Now we can compile a simple Add function with registerparams
(with registers enabled).
Change-Id: Ifdfac931052c0196096a1dd8b0687b5fdedb14d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/322850
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
for block control
In the scheduler we have the logic that if a Value is used as the
block's control, we schedule it at the end, except for Phis and
Args. Even the comment says so, the code doesn't exclude
in-register Args (OpArgXXXReg).
Change to check for score instead, which includes OpArgXXXRegs.
It also includes GetClosurePtr, which must be scheduled early.
We just happen to never use it as block control.
Found when working on ARM64 register ABI. In theory this could
apply to AMD64 as well. But on AMD64 we never use in-register
Value as block control, as conditional branch is always based on
FLAGS, never based on registers, so it doesn't actually cause any
problem.
Change-Id: I167a550309772639574f7468caf91bd805eb74c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/322849
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
This is a revert of https://go-review.googlesource.com/c/go/+/316890,
which has positive effects on debugging + DWARF variable locations
for register parameters when the reg abi is in effect, but also
turns out to interact badly with the register allocator.
Fixes #46304.
Change-Id: I624bd980493411a9cde45d44fcd3c46cad796909
Reviewed-on: https://go-review.googlesource.com/c/go/+/321830
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Don't add them to files in vendor and cmd/vendor though. These will be
pulled in by updating the respective dependencies.
For #41184
Change-Id: Icc57458c9b3033c347124323f33084c85b224c70
Reviewed-on: https://go-review.googlesource.com/c/go/+/319389
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
This CL add runtime.memmove inlining for AMD64 and ARM64.
According to ssa dump from testcases generic rules can't inline
memmomve properly due to one of the arguments is Phi operation. But this
Phi op will be optimized out by later optimization stages. As a result
memmove can be inlined during arch-specific rules.
The commit add new optimization rules to arch-specific rules that can
inline runtime.memmove if it possible during lowering stage.
Optimization fires 5 times in Go source-code using regabi.
Fixes #41662
Change-Id: Iaffaf4c482d068b5f0683d141863892202cc8824
Reviewed-on: https://go-review.googlesource.com/c/go/+/289151
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
|
|
steals idea from CL 312093
further investigation revealed additional duplicate
slots (equivalent, but not equal), so delete those too.
Rearranged Func.Names to be addresses of slots,
create canonical addresses so that split slots
(which use those addresses to refer to their parent,
and split slots can be further split)
will preserve "equivalent slots are equal".
Removes duplicates, improves metrics for "args at entry".
Change-Id: I5bbdcb50bd33655abcab3d27ad8cdce25499faaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/312292
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
These operations (BT{S,R,C}{Q,L}modify) are quite a bit slower than
other ways of doing the same thing.
Without the BTxmodify operations, there are two fallback ways the compiler
performs these operations: AND/OR/XOR operations directly on memory, or
load-BTx-write sequences. The compiler kinda chooses one arbitrarily
depending on rewrite rule application order. Currently, it uses
load-BTx-write for the Const benchmarks and AND/OR/XOR directly to memory
for the non-Const benchmarks. TBD, someone might investigate which of
the two fallback strategies is really better. For now, they are both
better than BTx ops.
name old time/op new time/op delta
BitSet-8 1.09µs ± 2% 0.64µs ± 5% -41.60% (p=0.000 n=9+10)
BitClear-8 1.15µs ± 3% 0.68µs ± 6% -41.00% (p=0.000 n=10+10)
BitToggle-8 1.18µs ± 4% 0.73µs ± 2% -38.36% (p=0.000 n=10+8)
BitSetConst-8 37.0ns ± 7% 25.8ns ± 2% -30.24% (p=0.000 n=10+10)
BitClearConst-8 30.7ns ± 2% 25.0ns ±12% -18.46% (p=0.000 n=10+10)
BitToggleConst-8 36.9ns ± 1% 23.8ns ± 3% -35.46% (p=0.000 n=9+10)
Fixes #45790
Update #45242
Change-Id: Ie33a72dc139f261af82db15d446cd0855afb4e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/318149
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
|
|
Add some rudimentary debug trace output for -N location list
generation if "-d=ssa/locationlists" is set.
Updates #45948.
Change-Id: If1a95730538a6e7def7ebe1ece1a71da8e5f0975
Reviewed-on: https://go-review.googlesource.com/c/go/+/317089
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
The code that created DWARF debug var locations for input parameters
in the non-optimized case for regabi was not doing the right thing for
degenerate functions with infinite loops. Detect these cases and don't
try to emit the normal location data.
Fixes #45948.
Change-Id: I2717fc4bac2e03d5d850a6ec8a09ed05fed0c896
Reviewed-on: https://go-review.googlesource.com/c/go/+/316752
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
When the expand_calls phase in the SSA backend lowers prolog OpArg
values into OpArgIntReg/OpArgFloatReg values, we don't always record
the assocation between the new lowered value and the parameter name.
This patch handles the simple case where a given parameter fits into
exactly one register; in this scenario it makes sense to manufacture a
new pseudo-slot for the value that points to the param, and install
the slot/value mapping in the NamedValues table for the function. More
work will be needed to deal with params that span multiple registers;
that will need to be addressed in a subsequent patch.
This change improves the parameter error rate "optargorder" benchmark
by about 7-8% (when run on the optargorder binary).
Updates #45945.
Change-Id: Ic9adbe20b6f91145d49651348818f0f5cba92b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/316890
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
This is part of getting debugging into good shape
with the register ABI. (This may generate a backport
for 1.16, there was some regression there as well.)
This is not necessarily fully-baked yet; my goal is to
make it work "well enough" for actual debugging, then
revisit the metrics, which are currently ignorant
of registers used for passing parameters (currently,
rejects them as a valid option).
Updates #40724.
Change-Id: Ib649adf39f947b7b54895c5bf181cf48ca4d38a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/311689
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Assignment between input parameters causes them to have more than
one "Name", and running this backwards from names to values can end
up confusing (conflating) parameter spill slots.
Around 105a6e9518, this cases a stack overflow running
go test -race encoding/pem
because two slice parameters spill (incorrectly) into the same
stack slots (in the AB?I-defined parameter spill area).
This also tickles a failure in cue, which turned out to be
easier to isolate.
Fixes #45851.
Updates #40724.
Change-Id: I39c56815bd6abb652f1ccbe83c47f4f373a125c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313212
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
When constructing multi-piece DWARF location expressions for
struct-typed parameters using the register ABI, make sure that the
location expressions generated properly reflect padding between
elements (this is required by debuggers). Example:
type small struct { x uint16 ; y uint8 ; z int32 }
func ABC(p1 int, p2 small, f1 float32) {
...
In the DWARF location expression for "p2" on entry to the routine, we
need pieces for each field, but for debuggers (such as GDB) to work
properly, we also need to describe the padding between elements. Thus
instead of
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 <rdi> DW_OP_piece 4
we need to emit
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 DW_OP_piece 1 <rdi> DW_OP_piece 4
This patch adds a new helper routine in abiutils to compute the
correct padding amounts for a struct type, a unit test for the helper,
and updates the debug generation code to call the helper and insert
apadding "piece" ops in the right spots.
Updates #40724.
Updates #45720.
Change-Id: Ie208bee25776b9eb70642041869e65e4fa65a005
Reviewed-on: https://go-review.googlesource.com/c/go/+/315071
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
Revise the code that generates DWARF location expressions for input
parameters to get it to work properly with the new register ABI when
optimization is turned off.
The previously implementation assumed stack locations for all
input+output parameters when -N (disable optimization) was in effect.
In the new implementation, a register-resident input parameter is
given a 2-element location list, the first list element pointing to
the ABI register(s) containing the param, and the second element
pointing to the stack home once it has been spilled.
NB, this change fixes a bunch of the Delve pkg/proc unit tests (maybe
about half of the outstanding failures). Still a good number that need
to be investigated, however.
Updates #40724.
Updates #45720.
Change-Id: I743bbb9af187bcdebeb8e690fdd6db58094ca415
Reviewed-on: https://go-review.googlesource.com/c/go/+/314431
Trust: Than McIntosh <thanm@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
The SSA code for debug variable location analysis (for DWARF) has two
special 'sentinel' values that it uses to handshake with the
debugInfo.GetPC callback when capturing the PC values of debug
variable ranges after prog generatoin: "BlockStart" and "BlockEnd".
"BlockStart" has the expected semantics: it means "the PC value of the
first instruction of block B", but "BlockEnd" does not mean "PC value
of the last instruction of block B", but rather it is implemented as
"the PC value of the last instruction of the function". This causes
confusion when reading the code, and seems to to result in implementation
flaws in the past, leading to incorrect ranges in some cases.
To help with this, add a new sentinel "FuncEnd" (which has the "last
inst in the function" semantics) and change the implementation of
"BlockEnd" to actually mean what its name implies (last inst in
block).
Updates #45720.
Change-Id: Ic3497fb60413e898d2bfe27805c3db56483d12a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314930
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Add a little more detail to the ssa README relating to GOSSAFUNC.
Update the -d=ssa help section to give a little more detail on what
to expect with applying the /debug=X qualifier to a phase.
Change-Id: I7027735f1f2955dbb5b9be36d9a648e8dc655048
Reviewed-on: https://go-review.googlesource.com/c/go/+/315229
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
In the register allocator, if possible, we allocate a value to its
desired register (the ideal register for its next use). In some
cases the desired register does not satisfies the value's output
register mask. We should not use the register in this case.
In the following example, v33 is going to be returned as a
function result, so it is allocated to its desired register AX.
However, its Op cannot use AX as output, causing miscompilation.
v33 = CMOVQEQF <int> v24 v28 v29 : AX (~R0[int])
v35 = MakeResult <int,int,mem> v33 v26 v18
Ret v35
Change-Id: Id0f4f27c4b233ee297e83077e3c8494fe193e664
Reviewed-on: https://go-review.googlesource.com/c/go/+/314630
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
In external linking mode the external linker may insert
trampolines, which use R12 as a scratch register. So a call could
potentially clobber R12 if the target is laid out too far. Mark
R12 clobbered.
Also, we will use R12 for trampolines in the Go linker as well.
CL 310731 updated the generated rewrite files so imports are
grouped, but the generator was not updated to do so. Grouped
imports are nice. But as those are generated files, for
simplicity and my laziness, just regenerate with the current
generator (which makes imports not grouped).
Change-Id: Iddb741ff7314a291ade5fbffc7d315f555808409
Reviewed-on: https://go-review.googlesource.com/c/go/+/314453
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
When the control value of a If block is known for a particular inbound edge
because its value can be inferred from the control value of its predecessor,
then this inbound edge can be redirected to the known successor directly,
This CL optimizes this kind of cases to eliminate unnecessary comparision.
For example, the following piece of code comes from runtime.atoi,
if !neg && un > uint(maxInt) {
return 0, false
}
if neg && un > uint(maxInt)+1 {
return 0, false
}
Before this optimization, if the first "if" statement does not return, both
conditions of the second "if" statement will be checked. But obviously the
value of neg is known through the first "if" statement, and there is no need
to check neg repeatedly.
After this optimization, this redundancy check is eliminated, and the execution
logic becomes as follows.
if !neg {
if un > uint(maxInt) {
return 0, false
}
} else {
if un > uint(maxInt)+1 {
return 0, false
}
}
This CL does not bring significant performance changes, but it makes the code
structure look more reasonable.
Statistical data from tool compilecmp on Linux/amd64:
name old time/op new time/op delta
Template 380ms ± 4% 385ms ± 3% +1.16% (p=0.000 n=50+49)
Unicode 168ms ± 9% 169ms ± 9% ~ (p=0.421 n=49+46)
GoTypes 1.99s ± 4% 2.02s ± 4% +1.48% (p=0.000 n=49+49)
Compiler 188ms ± 8% 188ms ± 9% ~ (p=0.997 n=49+50)
SSA 11.8s ± 2% 12.0s ± 2% +1.24% (p=0.000 n=48+50)
Flate 242ms ± 6% 244ms ± 9% ~ (p=0.307 n=46+49)
GoParser 361ms ± 3% 366ms ± 4% +1.23% (p=0.000 n=48+49)
Reflect 836ms ± 3% 842ms ± 3% +0.70% (p=0.004 n=48+48)
Tar 335ms ± 3% 340ms ± 4% +1.47% (p=0.000 n=49+46)
XML 432ms ± 4% 437ms ± 4% +1.11% (p=0.002 n=49+49)
LinkCompiler 701ms ± 4% 704ms ± 5% ~ (p=0.278 n=49+50)
ExternalLinkCompiler 1.83s ± 3% 1.84s ± 3% +0.51% (p=0.034 n=48+49)
LinkWithoutDebugCompiler 436ms ± 6% 438ms ± 6% ~ (p=0.419 n=48+49)
[Geo mean] 612ms 617ms +0.84%
name old alloc/op new alloc/op delta
Template 38.7MB ± 1% 39.1MB ± 1% +1.19% (p=0.000 n=50+50)
Unicode 28.1MB ± 0% 28.1MB ± 0% +0.20% (p=0.000 n=49+45)
GoTypes 168MB ± 1% 170MB ± 1% +1.05% (p=0.000 n=48+49)
Compiler 23.0MB ± 1% 23.1MB ± 1% +0.63% (p=0.000 n=50+50)
SSA 1.54GB ± 1% 1.55GB ± 1% +0.85% (p=0.000 n=50+50)
Flate 23.6MB ± 1% 23.9MB ± 1% +1.36% (p=0.000 n=43+46)
GoParser 35.0MB ± 1% 35.3MB ± 1% +0.94% (p=0.000 n=50+50)
Reflect 84.7MB ± 1% 86.1MB ± 1% +1.72% (p=0.000 n=49+49)
Tar 34.5MB ± 1% 34.9MB ± 1% +1.07% (p=0.000 n=47+48)
XML 44.2MB ± 3% 44.6MB ± 3% +0.70% (p=0.003 n=50+49)
LinkCompiler 128MB ± 0% 128MB ± 0% +0.01% (p=0.004 n=49+50)
ExternalLinkCompiler 120MB ± 0% 120MB ± 0% +0.01% (p=0.000 n=49+50)
LinkWithoutDebugCompiler 77.3MB ± 0% 77.3MB ± 0% +0.02% (p=0.000 n=50+50)
[Geo mean] 69.1MB 69.6MB +0.75%
file before after Δ %
addr2line 4049276 4051308 +2032 +0.050%
api 5248940 5248996 +56 +0.001%
asm 4868093 4868037 -56 -0.001%
buildid 2627666 2626026 -1640 -0.062%
cgo 4614432 4615040 +608 +0.013%
compile 23298888 23301267 +2379 +0.010%
cover 4591609 4591161 -448 -0.010%
dist 3449638 3450254 +616 +0.018%
doc 3925667 3926363 +696 +0.018%
fix 3322936 3323464 +528 +0.016%
link 6628632 6629560 +928 +0.014%
nm 3991753 3996497 +4744 +0.119%
objdump 4396119 4395615 -504 -0.011%
pack 2399719 2399535 -184 -0.008%
pprof 13616418 13622866 +6448 +0.047%
test2json 2646121 2646081 -40 -0.002%
trace 10233087 10226359 -6728 -0.066%
vet 7117994 7121066 +3072 +0.043%
total 111026988 111039495 +12507 +0.011%
On linux arm64:
name old time/op new time/op delta
Template 284ms ± 1% 286ms ± 1% +0.70% (p=0.000 n=49+50)
Unicode 125ms ± 3% 125ms ± 2% ~ (p=0.548 n=50+50)
GoTypes 1.69s ± 1% 1.71s ± 1% +1.02% (p=0.000 n=49+49)
Compiler 125ms ± 1% 124ms ± 2% -0.35% (p=0.020 n=50+50)
SSA 12.7s ± 1% 12.8s ± 1% +1.21% (p=0.000 n=49+49)
Flate 172ms ± 1% 173ms ± 1% +0.20% (p=0.047 n=50+50)
GoParser 265ms ± 1% 266ms ± 1% +0.64% (p=0.000 n=50+50)
Reflect 651ms ± 1% 650ms ± 1% ~ (p=0.079 n=48+48)
Tar 246ms ± 1% 246ms ± 1% ~ (p=0.202 n=50+46)
XML 328ms ± 1% 332ms ± 1% +1.28% (p=0.000 n=50+49)
LinkCompiler 600ms ± 1% 599ms ± 1% ~ (p=0.264 n=50+50)
ExternalLinkCompiler 1.88s ± 1% 1.90s ± 0% +1.36% (p=0.000 n=50+50)
LinkWithoutDebugCompiler 365ms ± 1% 365ms ± 1% ~ (p=0.602 n=50+46)
[Geo mean] 490ms 492ms +0.47%
name old alloc/op new alloc/op delta
Template 38.8MB ± 1% 39.1MB ± 1% +0.92% (p=0.000 n=44+42)
Unicode 28.4MB ± 0% 28.4MB ± 0% +0.22% (p=0.000 n=44+45)
GoTypes 169MB ± 1% 171MB ± 1% +1.12% (p=0.000 n=50+50)
Compiler 23.2MB ± 1% 23.3MB ± 1% +0.56% (p=0.000 n=42+43)
SSA 1.55GB ± 0% 1.56GB ± 0% +0.91% (p=0.000 n=48+49)
Flate 23.7MB ± 2% 24.0MB ± 1% +1.20% (p=0.000 n=50+50)
GoParser 35.3MB ± 1% 35.6MB ± 1% +0.88% (p=0.000 n=50+50)
Reflect 85.0MB ± 0% 86.5MB ± 0% +1.70% (p=0.000 n=49+48)
Tar 34.5MB ± 1% 34.9MB ± 1% +1.03% (p=0.000 n=47+50)
XML 43.8MB ± 2% 44.0MB ± 0% +0.41% (p=0.002 n=49+38)
LinkCompiler 136MB ± 0% 136MB ± 0% +0.01% (p=0.006 n=50+49)
ExternalLinkCompiler 127MB ± 0% 127MB ± 0% +0.02% (p=0.000 n=49+50)
LinkWithoutDebugCompiler 84.1MB ± 0% 84.1MB ± 0% ~ (p=0.534 n=50+50)
[Geo mean] 70.4MB 70.9MB +0.69%
file before after Δ %
addr2line 4006004 4004556 -1448 -0.036%
api 5029716 5028828 -888 -0.018%
asm 4936863 4934943 -1920 -0.039%
buildid 2594947 2594099 -848 -0.033%
cgo 4399702 4399502 -200 -0.005%
compile 22233139 22230486 -2653 -0.012%
cover 4443681 4443881 +200 +0.005%
dist 3365902 3365486 -416 -0.012%
doc 3776175 3776151 -24 -0.001%
fix 3218624 3218600 -24 -0.001%
link 6365001 6361409 -3592 -0.056%
nm 3923345 3923065 -280 -0.007%
objdump 4295473 4296673 +1200 +0.028%
pack 2390561 2389393 -1168 -0.049%
pprof 12866419 12865115 -1304 -0.010%
test2json 2587113 2585561 -1552 -0.060%
trace 9609814 9610846 +1032 +0.011%
vet 6790272 6789760 -512 -0.008%
total 106832751 106818354 -14397 -0.013%
Update: #37608
Change-Id: I2831238b12e3af5aef2261f64f804bf0a8b43f86
Reviewed-on: https://go-review.googlesource.com/c/go/+/244737
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Change-Id: Ibce07f8f36f7c64f7022ce656f8efbec5dff3f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/313829
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
With the new register ABI, the compiler sometimes introduces spills of
argument registers in function prologs; depending on the positions
assigned to these spills and whether they have the IsStmt flag set,
this can degrade the debugging experience. For example, in this
function from one of the Delve regression tests:
L13: func foo((eface interface{}) {
L14: if eface != nil {
L15: n++
L16: }
L17 }
we wind up with a prolog containing two spill instructions, the first
with line 14, the second with line 13. The end result for the user
is that if you set a breakpoint in foo and run to it, then do "step",
execution will initially stop at L14, then jump "backwards" to L13.
The root of the problem in this case is that an ArgIntReg pseudo-op is
introduced during expand calls, then promoted (due to lowering) to a
first-class statement (IsStmt flag set), which in turn causes
downstream handling to propagate its position to the first of the register
spills in the prolog.
To help improve things, this patch changes the rewriter to avoid
moving an "IsStmt" flag from a deleted/replaced instruction to an
Arg{Int,Float}Reg value, and adds Arg{Int,Float}Reg to the list of
opcodes not suitable for selection as statement boundaries, and
suppresses generation of additional register spills in defframe() when
optimization is disabled (since in that case things will get spilled
in any case).
This is not a comprehensive/complete fix; there are still cases where
we get less-than-ideal source position markers (ex: issue 45680).
Updates #40724.
Change-Id: Ica8bba4940b2291bef6b5d95ff0cfd84412a2d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/312989
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
If the address of an auto is used in a Call, we need to keep it,
as we keep the Call itself.
Fixes #45693.
Change-Id: Ie548d6dffc95bf916868a8885d4ab4cf9e86355a
Reviewed-on: https://go-review.googlesource.com/c/go/+/312670
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
instructions
For arm64 constant shift instructions, e.g., LSL(immediate), they use
only the low 6 bits. To conform the semantics of the hardware instructions,
this CL comments in ARM64OPS.go about restricted AuxInt ranges for the
various instructions involved.
Change-Id: I2b6560d6580e22ba7cbfa744a02b046dd5714b8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303569
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
This reverts CL 311829, and reenables CL 309330. The issue
should be fixed in the previous CL.
Change-Id: I69db0565c72470a1814f135d8f8ec62c781bfc5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/312094
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
Currently, in expand_calls, for each appearance of a named
variables's component, we add the named slot to f.Names list. If
a variable appears many times, we add it to f.Names many times.
Furthure, for each duplicated named slot, its entry in
f.NamedValues is a slice that contains all Values associated with
that name. This leads to quadratic behavior when iterating named
values like
for _, name := range f.Names {
for _, v := range f.NamedValues[name] {
...
}
}
This CL makes it not to add duplicated entries to f.Names.
Change-Id: I82a8d009db81ecf48b4577e0bca501feff677cdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/312093
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
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>
|
|
Apparently CL 309330 caused the compiler OOMing on some large
input (giant generated switch statement). I don't quite understand
it for now. Disable it for now.
Change-Id: I19c84f3f5e158897bff0b32d6217fcff3c66874d
Reviewed-on: https://go-review.googlesource.com/c/go/+/311829
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
