| Age | Commit message (Collapse) | Author |
|---|
|
This is a test for CL 720660.
For #76038
Change-Id: I2f630b738ddb5a9c48e3c5d4374c1e995910541a
Reviewed-on: https://go-review.googlesource.com/c/go/+/721480
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
This is a test for CL 719743.
Change-Id: I2d7b9d00d2d4dd63a21ca00f09eb7c9378ec70f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/721461
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
This is a test for CL 719440.
For #76038
Change-Id: I8fc55118b3c7dea39a36e04ffb060fcb6150af54
Reviewed-on: https://go-review.googlesource.com/c/go/+/721460
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
|
|
This ensures that the tests are testing the current linker sources,
not the installed linker.
Change-Id: I14a2ca9d413e1af57c7b5a00657c72023626a651
Reviewed-on: https://go-review.googlesource.com/c/go/+/721220
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
There is a test for this in CL 721480 later in this series.
For #76038
Change-Id: Ib7ed1f0b0aed2d929ca0f135b54d6b62112cae30
Reviewed-on: https://go-review.googlesource.com/c/go/+/720660
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Change-Id: I2d3c41b0e61b994d7b04bd16a791fd226dc45269
Reviewed-on: https://go-review.googlesource.com/c/go/+/720302
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
There is a test for this in CL 721461 later in this series.
For #76038
Change-Id: I15f9a8d0d5bd9424702a9ca7febb2fa76035aaf8
Reviewed-on: https://go-review.googlesource.com/c/go/+/719743
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
There is a test for this in CL 721460 later in this series.
For #76038
Change-Id: Icd7a52cbabde5162139dbc4b2c61306c0c748545
Reviewed-on: https://go-review.googlesource.com/c/go/+/719440
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Since before Go 1 the Go linker has handled ELF by first building the
ELF section string table, and then pointing ELF section headers to it.
This duplicates code as sections are effectively created twice,
once with the name and then again with the full section header.
The code duplication also means that it's easy to create unnecessary
section names; for example, every internally linked Go program
currently contains the string ".go.fuzzcntrs" although most do not
have a section by that name.
This CL changes the linker to simply build the section string table
after all the sections are known.
Change-Id: I27ba15b2af3dc1b8d7436b6c409f818aa8e6bfb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/718840
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I293e50e3a6ab19fb927099e106095d6aa1241b9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/718820
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
For an executable, emit the allocated section headers in address order,
so that section headers are easier for humans to read.
Change-Id: Ib5efb4734101e4a1f6b09d0e045ed643c79c7c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/718620
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: David Chase <drchase@google.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
memory after growslice
This CL is part of a set of CLs that attempt to reduce how much work the
GC must do. See the design in https://go.dev/design/74299-runtime-freegc
This CL updates the compiler to examine append calls to prove
whether or not the slice is aliased.
If proven unaliased, the compiler automatically inserts a call to a new
runtime function introduced with this CL, runtime.growsliceNoAlias,
which frees the old backing memory immediately after slice growth is
complete and the old storage is logically dead.
Two append benchmarks below show promising results, executing up to
~2x faster and up to factor of ~3 memory reduction with this CL.
The approach works with multiple append calls for the same slice,
including inside loops, and the final slice memory can be escaping,
such as in a classic pattern of returning a slice from a function
after the slice is built. (The final slice memory is never freed with
this CL, though we have other work that tackles that.)
An example target for this CL is we automatically free the
intermediate memory for the appends in the loop in this function:
func f1(input []int) []int {
var s []int
for _, x := range input {
s = append(s, g(x)) // s cannot be aliased here
if h(x) {
s = append(s, x) // s cannot be aliased here
}
}
return s // slice escapes at end
}
In this case, the compiler and the runtime collaborate so that
the heap allocated backing memory for s is automatically freed after
a successful grow. (For the first grow, there is nothing to free,
but for the second and subsequent growths, the old heap memory is
freed automatically.)
The new runtime.growsliceNoAlias is primarily implemented
by calling runtime.freegc, which we introduced in CL 673695.
The high-level approach here is we step through the IR starting
from a slice declaration and look for any operations that either
alias the slice or might do so, and treat any IR construct we
don't specifically handle as a potential alias (and therefore
conservatively fall back to treating the slice as aliased when
encountering something not understood).
For loops, some additional care is required. We arrange the analysis
so that an alias in the body of a loop causes all the appends in that
same loop body to be marked aliased, even if the aliasing occurs after
the append in the IR:
func f2() {
var s []int
for i := range 10 {
s = append(s, i) // aliased due to next line
alias = s
}
}
For nested loops, we analyse the nesting appropriately so that
for example this append is still proven as non-aliased in the
inner loop even though it aliased for the outer loop:
func f3() {
for range 10 {
var s []int
for i := range 10 {
s = append(s, i) // append using non-aliased slice
}
alias = s
}
}
A good starting point is the beginning of the test/escape_alias.go file,
which starts with ~10 introductory examples with brief comments that
attempt to illustrate the high-level approach.
For more details, see the new .../internal/escape/alias.go file,
especially the (*aliasAnalysis).analyze method.
In the first benchmark, an append in a loop builds up a slice from
nothing, where the slice elements are each 64 bytes. In the table below,
'count' is the number of appends. With 1 append, there is no opportunity
for this CL to free memory. Once there are 2 appends, the growth from
1 element to 2 elements means the compiler-inserted growsliceNoAlias
frees the 1-element array, and we see a ~33% reduction in memory use
and a small reported speed improvement.
As the number of appends increases for example to 5, we are at
a ~20% speed improvement and ~45% memory reduction, and so on until
we reach ~40% faster and ~50% less memory allocated at the end of
the table.
There can be variation in the reported numbers based on -randlayout, so
this table is for 30 different values of -randlayout with a total
n=150. (Even so, there is still some variation, so we probably should
not read too much into small changes.) This is with GOAMD64=v3 on
a VM that gcc reports is cascadelake.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
Append64Bytes/count=1-4 31.09n ± 2% 31.69n ± 1% +1.95% (n=150)
Append64Bytes/count=2-4 73.31n ± 1% 70.27n ± 0% -4.15% (n=150)
Append64Bytes/count=3-4 142.7n ± 1% 124.6n ± 1% -12.68% (n=150)
Append64Bytes/count=4-4 149.6n ± 1% 127.7n ± 0% -14.64% (n=150)
Append64Bytes/count=5-4 277.1n ± 1% 213.6n ± 0% -22.90% (n=150)
Append64Bytes/count=6-4 280.7n ± 1% 216.5n ± 1% -22.87% (n=150)
Append64Bytes/count=10-4 544.3n ± 1% 386.6n ± 0% -28.97% (n=150)
Append64Bytes/count=20-4 1058.5n ± 1% 715.6n ± 1% -32.39% (n=150)
Append64Bytes/count=50-4 2.121µ ± 1% 1.404µ ± 1% -33.83% (n=150)
Append64Bytes/count=100-4 4.152µ ± 1% 2.736µ ± 1% -34.11% (n=150)
Append64Bytes/count=200-4 7.753µ ± 1% 4.882µ ± 1% -37.03% (n=150)
Append64Bytes/count=400-4 15.163µ ± 2% 9.273µ ± 1% -38.84% (n=150)
geomean 601.8n 455.0n -24.39%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
Append64Bytes/count=1-4 64.00 ± 0% 64.00 ± 0% ~ (n=150)
Append64Bytes/count=2-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
Append64Bytes/count=3-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=4-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
Append64Bytes/count=5-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=6-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
Append64Bytes/count=10-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
Append64Bytes/count=20-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
Append64Bytes/count=50-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
Append64Bytes/count=100-4 15.938Ki ± 0% 8.021Ki ± 0% -49.67% (n=150)
Append64Bytes/count=200-4 31.94Ki ± 0% 16.08Ki ± 0% -49.64% (n=150)
Append64Bytes/count=400-4 63.94Ki ± 0% 32.33Ki ± 0% -49.44% (n=150)
geomean 1.991Ki 1.124Ki -43.54%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
Append64Bytes/count=1-4 1.000 ± 0% 1.000 ± 0% ~ (n=150)
Append64Bytes/count=2-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
Append64Bytes/count=3-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=4-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
Append64Bytes/count=5-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=6-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
Append64Bytes/count=10-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
Append64Bytes/count=20-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
Append64Bytes/count=50-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
Append64Bytes/count=100-4 8.000 ± 0% 1.000 ± 0% -87.50% (n=150)
Append64Bytes/count=200-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
Append64Bytes/count=400-4 10.000 ± 0% 1.000 ± 0% -90.00% (n=150)
geomean 4.331 1.000 -76.91%
The second benchmark is similar, but instead uses an 8-byte integer
for the slice element. The first 4 appends in the loop never call into
the runtime thanks to the excellent CL 664299 introduced by Keith in
Go 1.25 that allows some <= 32 byte dynamically-sized slices to be on
the stack, so this CL is neutral for <= 32 bytes. Once the 5th append
occurs at count=5, a grow happens via the runtime and heap allocates
as normal, but freegc does not yet have anything to free, so we see
a small ~1.4ns penalty reported there. But once the second growth
happens, the older heap memory is now automatically freed by freegc,
so we start to see some benefit in memory reductions and speed
improvements, starting at a tiny speed improvement (close to a wash,
or maybe noise) by the second growth before count=10, and building up to
~2x faster with ~68% fewer allocated bytes reported.
goos: linux
goarch: amd64
pkg: runtime
cpu: Intel(R) Xeon(R) CPU @ 2.80GHz
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ sec/op │ sec/op vs base │
AppendInt/count=1-4 2.978n ± 0% 2.969n ± 0% -0.30% (p=0.000 n=150)
AppendInt/count=4-4 4.292n ± 3% 4.163n ± 3% ~ (p=0.528 n=150)
AppendInt/count=5-4 33.50n ± 0% 34.93n ± 0% +4.25% (p=0.000 n=150)
AppendInt/count=10-4 76.21n ± 1% 75.67n ± 0% -0.72% (p=0.000 n=150)
AppendInt/count=20-4 150.6n ± 1% 133.0n ± 0% -11.65% (n=150)
AppendInt/count=50-4 284.1n ± 1% 225.6n ± 0% -20.59% (n=150)
AppendInt/count=100-4 544.2n ± 1% 392.4n ± 1% -27.89% (n=150)
AppendInt/count=200-4 1051.5n ± 1% 702.3n ± 0% -33.21% (n=150)
AppendInt/count=400-4 2.041µ ± 1% 1.312µ ± 1% -35.70% (n=150)
AppendInt/count=1000-4 5.224µ ± 2% 2.851µ ± 1% -45.43% (n=150)
AppendInt/count=2000-4 11.770µ ± 1% 6.010µ ± 1% -48.94% (n=150)
AppendInt/count=3000-4 17.747µ ± 2% 8.264µ ± 1% -53.44% (n=150)
geomean 331.8n 246.4n -25.72%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ B/op │ B/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 64.00 ± 0% 64.00 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 192.0 ± 0% 128.0 ± 0% -33.33% (n=150)
AppendInt/count=20-4 448.0 ± 0% 256.0 ± 0% -42.86% (n=150)
AppendInt/count=50-4 960.0 ± 0% 512.0 ± 0% -46.67% (n=150)
AppendInt/count=100-4 1.938Ki ± 0% 1.000Ki ± 0% -48.39% (n=150)
AppendInt/count=200-4 3.938Ki ± 0% 2.001Ki ± 0% -49.18% (n=150)
AppendInt/count=400-4 7.938Ki ± 0% 4.005Ki ± 0% -49.54% (n=150)
AppendInt/count=1000-4 24.56Ki ± 0% 10.05Ki ± 0% -59.07% (n=150)
AppendInt/count=2000-4 58.56Ki ± 0% 20.31Ki ± 0% -65.32% (n=150)
AppendInt/count=3000-4 85.19Ki ± 0% 27.30Ki ± 0% -67.95% (n=150)
geomean ² -42.81%
│ old-1bb1f2bf0c │ freegc-8ba7421-ps16 │
│ allocs/op │ allocs/op vs base │
AppendInt/count=1-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=4-4 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=5-4 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=150)
AppendInt/count=10-4 2.000 ± 0% 1.000 ± 0% -50.00% (n=150)
AppendInt/count=20-4 3.000 ± 0% 1.000 ± 0% -66.67% (n=150)
AppendInt/count=50-4 4.000 ± 0% 1.000 ± 0% -75.00% (n=150)
AppendInt/count=100-4 5.000 ± 0% 1.000 ± 0% -80.00% (n=150)
AppendInt/count=200-4 6.000 ± 0% 1.000 ± 0% -83.33% (n=150)
AppendInt/count=400-4 7.000 ± 0% 1.000 ± 0% -85.71% (n=150)
AppendInt/count=1000-4 9.000 ± 0% 1.000 ± 0% -88.89% (n=150)
AppendInt/count=2000-4 11.000 ± 0% 1.000 ± 0% -90.91% (n=150)
AppendInt/count=3000-4 12.000 ± 0% 1.000 ± 0% -91.67% (n=150)
geomean ² -72.76% ²
Of course, these are just microbenchmarks, but likely indicate
there are some opportunities here.
The immediately following CL 712422 tackles inlining and is able to get
runtime.freegc working automatically with iterators such as used by
slices.Collect, which becomes able to automatically free the
intermediate memory from its repeated appends (which earlier
in this work required a temporary hand edit to the slices package).
For now, we only use the NoAlias version for element types without
pointers while waiting on additional runtime support in CL 698515.
Updates #74299
Change-Id: I1b9d286aa97c170dcc2e203ec0f8ca72d84e8221
Reviewed-on: https://go-review.googlesource.com/c/go/+/710015
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
When a function call exceeds the immediate value range of the instruction,
a trampoline is required to assist in the jump. Trampoline is only omitted
when plt is needed; otherwise, a check is required.
Change-Id: I7fe2e08d75f6f574475837b560e650bbd4215858
Reviewed-on: https://go-review.googlesource.com/c/go/+/724580
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
The loong64 ISA does not support the 32-bit unsigned arithmetic
instructions ADDU, SUBU and MULU.
Change-Id: Ifa67de9c59aa12d08844189ed23e6daad0cc11ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/722760
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Both CL 722161 and CL 724140 implement a more general solution to
detecting cycles involving values of a type on the object path.
The logic in literals.go was intended to be a stop-gap solution and
is no longer necessary.
Change-Id: I328c0febf35444f07fc1894278dc76ab140710bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/724380
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
|
|
CL 722161 replaced the setDefType mechanism with boundaries on composite
literals, removing the need to pass the def argument in all but 1 case.
The exception is interface types, which use def to populate the receiver
type for better error messages.
Change-Id: Ic78c91238588015153f0d22790be5872a01c5f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/723920
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
|
|
Given a type definition of the form:
type T RHS
The setDefType function would set T.fromRHS as soon as we knew its
top-level type. For instance, in:
type S struct { ... }
S.fromRHS is set to a struct type before type-checking anything inside
the struct.
This permit access to the (incomplete) RHS type in a cyclic type
declaration. Accessing this information is fraught (as it's incomplete),
but was used for reporting certain types of cycles.
This CL replaces setDefType with a check that ensures no value of type
T is used before its RHS is set up.
This CL is strictly more complete than what setDefType achieved. For
instance, it enables correct reporting for the below cycles:
type A [unsafe.Sizeof(A{})]int
var v any = 42
type B [v.(B)]int
func f() C {
return C{}
}
type C [unsafe.Sizeof(f())]int
Fixes #76383
Fixes #76384
Change-Id: I9dfab5b708013b418fa66e43362bb4d8483fedec
Reviewed-on: https://go-review.googlesource.com/c/go/+/724140
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Implement secret.Do.
- When secret.Do returns:
- Clear stack that is used by the argument function.
- Clear all the registers that might contain secrets.
- On stack growth in secret mode, clear the old stack.
- When objects are allocated in secret mode, mark them and then zero
the marked objects immediately when they are freed.
- If the argument function panics, raise that panic as if it originated
from secret.Do. This removes anything about the secret function
from tracebacks.
For now, this is only implemented on linux for arm64 and amd64.
This is a rebased version of Keith Randalls initial implementation at
CL 600635. I have added arm64 support, signal handling, preemption
handling and dealt with vDSOs spilling into system stacks.
Fixes #21865
Change-Id: I6fbd5a233beeaceb160785e0c0199a5c94d8e520
Co-authored-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/704615
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
CL 688815 contained a partial fix for the reported bug, but
NewSignatureType continued to panic. This change relaxes it
to permit construction of the type "func([]byte, B) []byte"
where "type B []byte". We must do so because a client
may instantiate the type "func([]byte, T...)" where [T ~string|~[]byte]
at T=B, and may have no way to know that they are dealing
with this very special edge case of append.
Added a regression test of NewSignatureType, which I should
have done in the earlier CL.
Also, make typestring less pedantic and fragile.
Fixes #73871
Change-Id: I3d8f8609582149f9c9f8402a04ad516c2c63bbc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/689277
TryBot-Bypass: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
This CL change getNameFrom impl to pattern match addressible patterns.
Change-Id: If1faa22a3a012d501e911d8468a5702b348abf16
Reviewed-on: https://go-review.googlesource.com/c/go/+/724180
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
There's a comment that we should test that compile -c is compatible with
the fieldtrack and preemptibleloops experiments and then remove the
check disabling -c when those experiments are enabled.
I tested this and the tests pass with fieldtrack (with the exception of one go command test that makes the assumption that fieldtrack is off), and the preemptibleloops experiment is already broken without this experiment.
Also remove the check for the value of the GO19CONCURRENTCOMPILATION
environment variable. The compiler concurrency can be limited by setting
GOMAXPROCS.
Change-Id: I0c02745de463ea572673648061185cd76a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/724680
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Also update comment in cmd/dist's broken map to point to the top-level
umbrella issue.
For #76475.
For #75005.
Change-Id: I43b8384af4264dc5d72ceea8d05730b9db81123a
Reviewed-on: https://go-review.googlesource.com/c/go/+/724860
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
|
|
If simd experiment is not enabled, the compiler doesn't use the
AVX part of the register. So only zero it with the SSE instruction.
Change-Id: Ia3bdf34a9ed273128db2ee0f4f5db6f7cc76a975
Reviewed-on: https://go-review.googlesource.com/c/go/+/724720
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Previously we limited the value we passed in to compile -c (which set
the number of SSA compile goroutines that run at one time) to 4. This CL
allows the -c value to go up to GOMAXPROCS, while limiting the total
number of backend SSA compile goroutines to still be less than the
previous worst case of 4*GOMAXPROCS (actually four times the value of
the -p flag, but the default is GOMAXPROCS). We do that by keeping a
pool of tokens to represent the total number of SSA compile goroutines
(with some buffer to allow us to run out of tokens and not exceed
4*GOMAXPROCS). Each time a compile requests a -c value, we'll hand out
half of the remaining tokens (with the number handed otu capped at
GOMAXPROCS) until we run out of tokens, in wich case we'll set -c to
one.
This leads to a speed up of 3-10% on the 16 core intel perf builder and
5-16% on the 88 core builder on the Sweet go-build benchmark.
Change-Id: Ib1ec843fee57f0fb8d36a507162317276a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/724142
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
Don't use the move2heap optimization if the move2heap is inside
a loop deeper than the declaration of the slice. We really only want
to do the move2heap operation once.
Change-Id: I4a68d01609c2c9d4e0abe4580839e70059393a81
Reviewed-on: https://go-review.googlesource.com/c/go/+/722440
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Special-case an sprintf argument of []*operand type, similar to what
we do for other lists. As a result a list of operands is printed as
[a, b, c] rather than [a b c] (default formatting for slices).
(We could factor out this code into a generic function, but this is
a minimally intrusive change at this point.)
Change-Id: Iea4fc6ea375dd9618316b7317a77b57b4e35544d
Reviewed-on: https://go-review.googlesource.com/c/go/+/724500
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
|
|
Go asm syntax:
VMADD{B, H, W, V} V1, V2, V3
VMSUB{B, H, W, V} V1, V2, V3
XVMADD{B, H, W, V} X1, X2, X3
XVMSUB{B, H, W, V} X1, X2, X3
VMADDWEV{HB, WH, VW,QV}{,U} V1, V2, V3
VMADDWOD{HB, WH, VW,QV}{,U} V1, V2, V3
XVMADDWEV{HB, WH, VW,QV}{,U} X1, X2, X3
XVMADDWOD{HB, WH, VW,QV}{,U} X1, X2, X3
VMADDWEV{HBUB, WHUH, VWUW, QVUV} V1, V2, V3
VMADDWOD{HBUB, WHUH, VWUW, QVUV} V1, V2, V3
XVMADDWEV{HBUB, WHUH, VWUW, QVUV} X1, X2, X3
XVMADDWOD{HBUB, WHUH, VWUW, QVUV} X1, X2, X3
Equivalent platform assembler syntax:
vmadd.{b,h,w,d} v3, v2, v1
vmsub.{b,h,w,d} v3, v2, v1
xvmadd.{b,h,w,d} x3, x2, x1
xvmsub.{b,h,w,d} x3, x2, x1
vmaddwev.{h.b, w.h, d.w, q.d}{,u} v3, v2, v1
vmaddwod.{h.b, w.h, d.w, q.d}{,u} v3, v2, v1
xvmaddwev.{h.b, w.h, d.w, q.d}{,u} x3, x2, x1
xvmaddwod.{h.b, w.h, d.w, q.d}{,u} x3, x2, x1
vmaddwev.{h.bu.b, d.wu.w, d.wu.w, q.du.d} v3, v2, v1
vmaddwod.{h.bu.b, d.wu.w, d.wu.w, q.du.d} v3, v2, v1
xvmaddwev.{h.bu.b, d.wu.w, d.wu.w, q.du.d} x3, x2, x1
xvmaddwod.{h.bu.b, d.wu.w, d.wu.w, q.du.d} x3, x2, x1
Change-Id: I2f4aae51045e1596d4744e525a1589586065cf8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/724200
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
|
|
Both the MULW and MUL instructions point to the mul.w instruction
in the loong64 ISA. Previously, MULW was not encoded; now it is
encoded and used as an alias for MUL.
The same applies to the following instructions: ADD, SUB, DIV.
For consistency, we have added additional aliases for DIVU, REM and REMU.
Change-Id: Iba201a3c4c2893ff7d301ef877fad9c81e54291b
Reviewed-on: https://go-review.googlesource.com/c/go/+/721523
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I9d8bd78a06738a8a242b6965382e61568e93dea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/724620
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@google.com>
|
|
I had to improve addition to make the tests pass.
Change-Id: I4daba2ee0f24a0dbc3929bf9afadd2116e16efae
Reviewed-on: https://go-review.googlesource.com/c/go/+/724600
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Auto-Submit: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Introduce a new MemEq SSA operation for runtime.memequal. The operation
is initially implemented for arm64. The change adds opt rules (following
existing rules for call to runtime.memequal), working with MemEq, and a
later op version LoweredMemEq which may be lowered differently for more
constant size cases in future (for other targets as well as for arm64).
The new MemEq SSA operation does not have memory result, allowing cse of
loads operations around it.
Code size difference (for arm64 linux):
Executable Old .text New .text Change
-------------------------------------------------------
asm 1970420 1969668 -0.04%
cgo 1741220 1740212 -0.06%
compile 8956756 8959428 +0.03%
cover 1879332 1878772 -0.03%
link 2574116 2572660 -0.06%
preprofile 867124 866820 -0.04%
vet 2890404 2888596 -0.06%
Change-Id: I6ab507929b861884d17d5818cfbd152cf7879751
Reviewed-on: https://go-review.googlesource.com/c/go/+/686655
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
This commit removes the final references to the global Fetcher_ variable from
the modfetch and modload packages.
This completes the removal of global state from the modfetch package.
Change-Id: Ibb5309acdc7d05f1a7591ddcf890b44b6cc4cb2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/724249
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This commit removes references to the global modfetch.Fetcher_
variable from the toolchain package.
Change-Id: Id366bec88e5904098b90371ec103f92d402174d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/724248
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This commit removes references to the global modfetch.Fetcher_
variable from the modget package.
Change-Id: I62dfcc0e9cf9722a6706bbdf7b6e561130ed82d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/724247
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
This commit removes references to the global modfetch.Fetcher_
variable from the load package.
Change-Id: Ic579743079252afd4d2d12e5118de09d86340267
Reviewed-on: https://go-review.googlesource.com/c/go/+/724246
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
This commit removes references to the global modfetch.Fetcher_
variable from the modcmd package.
Change-Id: Ie2966401d1f6964e21ddede65d39ff53fea6e867
Reviewed-on: https://go-review.googlesource.com/c/go/+/724245
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
TLDR
- not-huge increase to default starting heap boost,
- small improvement in build performance,
- remove concurrency dependence of starting heap,
- aligns RSS behavior with GOMEMLIMIT,
- adds a gcflags=-d=gcstart=N (N -> N MiB) flag for
people who want to trade a lot of memory for a
little build performance improvement.
This removes concurrency (-c flag) sensitivity and increases the
nominal default to 128MiB.
Refactored the startheap code into a separate file, to make it
easier to extract and reuse.
Added sensitivity to concurrency=1 and GOMEMLIMIT!="" (in addition
to existing GOGC!=""), those disable the default starting heap boost
because the compiler-invoker has indicated either a desire to control
the GC or a desire to run in minimum memory(or both).
Adds a -d flag gcstart=N (N is number of MiB) for
tinkering/experiments. This always enables the starting heap.
(`GOGC=XXX` and `-d=gcstart=YYY` will use `GOGC=XXX` after starting
heap size is achieved.)
Derated the "boost" obtained by a factor of .70 so that
`-d=gcstart=2000` yields the same RSS as `GOMEMLIMIT=2000MiB`
(Actually adjusts the boost with a high-low breakpoint.)
The parent, with concurrency sensitivity, provided 64MB of plain
boost. Derating reduces the effects of boosting the starting heap
slightly. The benchmark here shows that maintaining 64MB results in
a minor regression, while increasing it to 128MB produces a slight
improvement, and does not grow the RSS versus 64MB.
```
│ parent │ sh64 │ sh128 │ sh1024 │
│ sec/op │ sec/op vs base │ sec/op vs base │ sec/op vs base │
std 10.164 ± 1% 10.527 ± 1% +3.57% (p=0.000 n=50) 10.084 ± 1% -0.79% (p=0.000 n=50) 9.631 ± 1% -5.24% (p=0.000 n=50)
compile 21.05 ± 1% 20.78 ± 0% -1.28% (p=0.000 n=50) 20.74 ± 1% -1.46% (p=0.000 n=50) 20.77 ± 0% -1.32% (p=0.001 n=50)
ast 20.45 ± 1% 20.39 ± 1% ~ (p=0.334 n=50) 20.44 ± 0% ~ (p=0.818 n=50) 20.11 ± 1% -1.65% (p=0.000 n=50)
geomean 16.35 16.46 +0.65% 16.23 -0.76% 15.90 -2.75%
│ parent │ sh64 │ sh128 │ sh1024 │
│ user-sec/op │ user-sec/op vs base │ user-sec/op vs base │ user-sec/op vs base │
std 66.06 ± 0% 69.74 ± 0% +5.56% (p=0.000 n=50) 64.68 ± 0% -2.09% (p=0.000 n=50) 59.51 ± 0% -9.91% (p=0.000 n=50)
compile 84.69 ± 1% 82.54 ± 0% -2.53% (p=0.000 n=50) 82.63 ± 0% -2.43% (p=0.000 n=50) 82.66 ± 1% -2.40% (p=0.000 n=50)
ast 59.41 ± 0% 58.84 ± 1% -0.95% (p=0.011 n=50) 59.48 ± 1% ~ (p=0.341 n=50) 57.13 ± 1% -3.83% (p=0.000 n=50)
geomean 69.27 69.71 +0.63% 68.25 -1.47% 65.50 -5.44%
│ parent │ sh64 │ sh128 │ sh1024 │
│ sys-sec/op │ sys-sec/op vs base │ sys-sec/op vs base │ sys-sec/op vs base │
std 9.599 ± 1% 10.031 ± 1% +4.50% (p=0.000 n=50) 9.513 ± 1% -0.90% (p=0.014 n=50) 9.359 ± 1% -2.50% (p=0.000 n=50)
compile 6.813 ± 1% 6.740 ± 1% -1.08% (p=0.017 n=50) 6.716 ± 1% -1.42% (p=0.006 n=50) 6.696 ± 1% -1.72% (p=0.000 n=50)
ast 4.315 ± 1% 4.291 ± 1% ~ (p=0.781 n=50) 4.296 ± 1% ~ (p=0.792 n=50) 4.279 ± 2% ~ (p=0.124 n=50)
geomean 6.559 6.620 +0.93% 6.499 -0.92% 6.449 -1.68%
│ parent │ sh64 │ sh128 │ sh1024 │
│ peak-RSS-bytes │ peak-RSS-bytes vs base │ peak-RSS-bytes vs base │ peak-RSS-bytes vs base │
std 257.1Mi ± 1% 257.2Mi ± 1% ~ (p=0.754 n=50) 257.0Mi ± 0% ~ (p=0.570 n=50) 605.6Mi ± 0% +135.59% (p=0.000 n=50)
compile 1007.2Mi ± 1% 1004.3Mi ± 0% ~ (p=0.064 n=50) 1007.4Mi ± 0% ~ (p=0.348 n=50) 1009.4Mi ± 1% ~ (p=0.598 n=50)
ast 1.848Gi ± 0% 1.842Gi ± 0% ~ (p=0.079 n=50) 1.824Gi ± 0% -1.25% (p=0.000 n=50) 1.856Gi ± 0% +0.47% (p=0.000 n=50)
geomean 788.3Mi 786.8Mi -0.19% 785.0Mi -0.41% 1.027Gi +33.37%
```
Updates #73044
Change-Id: I6359642a94b396e696dd57e64ed1f2c4cf178475
Reviewed-on: https://go-review.googlesource.com/c/go/+/724441
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This commit removes references to the global Fetcher_ variable from
the zip sum test file.
Change-Id: I622587f7809f4c6bcd4afbb35312912149b7a3ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/724244
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
This commit replaces references of modfetch.Fetcher_ with
modload.State.Fetcher() in the modload package. Note that the
constructor `NewState` still intentionally references the global
variable. This will be refactored in a later commit.
Change-Id: Ia8cfb41a81b0e29043694bc0f0f33f5a2f4920c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/724243
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
This commit continues the injection of the global Fetcher_ variable into
the various function calls that make use of it. The purpose is to
prepare for the eventual removal of the global Fetcher_ variable and
eliminate global state within the modfetch package.
[git-generate]
cd src/cmd/go/internal/modcmd
rf '
inject modfetch.Fetcher_ DownloadModule
'
cd ../modfetch
rf '
add downloadZip:/f, err := tempFile.*/+0 _ = f \
file, err := tempFile(ctx, filepath.Dir(zipfile), filepath.Base(zipfile), 0o666) \
_ = file
'
rf '
add downloadZip:/f.Close\(\)/+0 file.Close()
rm downloadZip:/file.Close\(\)/-1
add downloadZip:/os.Remove\(f.Name\(\)\)/+0 os.Remove(file.Name())
rm downloadZip:/os.Remove\(file.Name\(\)\)/-1
'
sed -i '
s/ f, err := tempFile(ctx, filepath.Dir(zipfile), filepath.Base(zipfile), 0o666)/file, err := tempFile(ctx, filepath.Dir(zipfile), filepath.Base(zipfile), 0o666)/
s/err := repo.Zip(ctx, f, mod.Version)/err := repo.Zip(ctx, file, mod.Version)/
s/if _, err := f.Seek(0, io.SeekStart); err != nil {/if _, err := file.Seek(0, io.SeekStart); err != nil {/
s/if err := f.Truncate(0); err != nil {/if err := file.Truncate(0); err != nil {/
s/fi, err := f.Stat()/fi, err := file.Stat()/
s/z, err := zip.NewReader(f, fi.Size())/z, err := zip.NewReader(file, fi.Size())/
s/for _, f := range z.File {/for _, zf := range z.File {/
s/if !strings.HasPrefix(f.Name, prefix) {/if !strings.HasPrefix(zf.Name, prefix) {/
s/return fmt.Errorf("zip for %s has unexpected file %s", prefix\[:len(prefix)-1\], f.Name)/return fmt.Errorf("zip for %s has unexpected file %s", prefix[:len(prefix)-1], zf.Name)/
s/if err := f.Close(); err != nil {/if err := file.Close(); err != nil {/
s/if err := hashZip(fetcher_, mod, f.Name(), ziphashfile); err != nil {/if err := hashZip(fetcher_, mod, file.Name(), ziphashfile); err != nil {/
s/if err := os.Rename(f.Name(), zipfile); err != nil {/if err := os.Rename(file.Name(), zipfile); err != nil {/
' fetch.go
rf '
rm downloadZip:/_ = file/-3 downloadZip:/_ = file/-2 downloadZip:/file, err := tempFile\(ctx, filepath.Dir\(zipfile\), filepath.Base\(zipfile\), 0o666\)/+1
'
rf '
mv InfoFile.fetcher_ InfoFile.f
mv InfoFile Fetcher.InfoFile
mv GoModFile.fetcher_ GoModFile.f
mv GoModFile Fetcher.GoModFile
mv GoModSum.fetcher_ GoModSum.f
mv GoModSum Fetcher.GoModSum
mv Download.fetcher_ Download.f
mv Download Fetcher.Download
mv download.fetcher_ download.f
mv download Fetcher.download
mv DownloadZip.fetcher_ DownloadZip.f
mv DownloadZip Fetcher.DownloadZip
mv downloadZip.fetcher_ downloadZip.f
mv downloadZip Fetcher.downloadZip
mv checkMod.fetcher_ checkMod.f
mv checkMod Fetcher.checkMod
mv hashZip.fetcher_ hashZip.f
'
Change-Id: I1d2e09b8523f5ef2be04b91d858d98fb79c0a771
Reviewed-on: https://go-review.googlesource.com/c/go/+/724242
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
This commit continues the injection of the global Fetcher_ variable into
the various function calls that make use of it. The purpose is to
prepare for the eventual removal of the global Fetcher_ variable and
eliminate global state within the modfetch package.
[git-generate]
cd src/cmd/go/internal/modload
rf '
inject modfetch.Fetcher_ commitRequirements
mv readModGraph.fetcher_ readModGraph.f
'
cd ../modfetch
sed -i '
s/for _, f := range fetcher_.workspaceGoSumFiles {/for _, fn := range fetcher_.workspaceGoSumFiles {/
s/fetcher_.sumState.w\[f\] = make(map\[module.Version\]\[\]string)/fetcher_.sumState.w[fn] = make(map[module.Version][]string)/
s/_, err := readGoSumFile(fetcher_.sumState.w\[f\], f)/_, err := readGoSumFile(fetcher_.sumState.w[fn], fn)/
' fetch.go
rf '
mv GoMod.fetcher_ GoMod.f
mv GoMod Fetcher.GoMod
mv readDiskGoMod.fetcher_ readDiskGoMod.f
mv readDiskGoMod Fetcher.readDiskGoMod
mv initGoSum.fetcher_ initGoSum.f
mv initGoSum Fetcher.initGoSum
mv HaveSum.fetcher_ HaveSum.f
mv checkGoMod.fetcher_ checkGoMod.f
mv checkModSum.fetcher_ checkModSum.f
mv WriteGoSum.fetcher_ WriteGoSum.f
mv WriteGoSum Fetcher.WriteGoSum
mv Lookup.fetcher_ Lookup.f
mv Lookup Fetcher.Lookup
'
Change-Id: Ifbe7d6b90b93fd65a7443434035921e6b42dea1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/724241
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
This commit begins the injection of the global Fetcher_ variable into
the various function calls that make use of it. The purpose is to
prepare for the eventual removal of the global Fetcher_ variable and
eliminate global state.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
inject Fetcher_ TidyGoSum
mv haveModSumLocked.fetcher_ haveModSumLocked.f
mv addModSumLocked.fetcher_ addModSumLocked.f
mv tidyGoSum.fetcher_ tidyGoSum.f
mv sumInWorkspaceModulesLocked.fetcher_ sumInWorkspaceModulesLocked.f
'
Change-Id: Iecf736f17d6e63c856355284d09b7982dc9e16b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/724240
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
instructions support
Go asm syntax:
VADDWEV{HB, WH, VW, QV}{,U} V1, V2, V3
VSUBWEV{HB, WH, VW, QV}{,U} V1, V2, V3
VADDWOD{HB, WH, VW, QV}{,U} V1, V2, V3
VSUBWOD{HB, WH, VW, QV}{,U} V1, V2, V3
XVADDWEV{HB, WH, VW, QV}{,U} X1, X2, X3
XVSUBWEV{HB, WH, VW, QV}{,U} X1, X2, X3
XVADDWOD{HB, WH, VW, QV}{,U} X1, X2, X3
XVSUBWOD{HB, WH, VW, QV}{,U} X1, X2, X3
Equivalent platform assembler syntax:
vaddwev.{h.b, w.h, d.w, q.d}{,u} V3, V2, V1
vsubwev.{h.b, w.h, d.w, q.d}{,u} V3, V2, V1
vaddwod.{h.b, w.h, d.w, q.d}{,u} V3, V2, V1
vsubwod.{h.b, w.h, d.w, q.d}{,u} V3, V2, V1
xvaddwev.{h.b, w.h, d.w, q.d}{,u} X3, X2, X1
xvsubwev.{h.b, w.h, d.w, q.d}{,u} X3, X2, X1
xvaddwod.{h.b, w.h, d.w, q.d}{,u} X3, X2, X1
xvsubwod.{h.b, w.h, d.w, q.d}{,u} X3, X2, X1
Change-Id: I407dc65b32b89844fd303e265a99d8aafdf922ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/723620
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
Reviewed-by: sophie zhao <zhaoxiaolin@loongson.cn>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
This should mark the end of the conversion table, except for float16
which does not exist on Go yet.
The rounding logic documentation of float64 -> float32 is based on
abi-internal default MXCSR:
| RC | 14/13 | 0 (RN) | Round to nearest |
Change-Id: I27a86560e8d74d20f21350bf78314b4eada20ec0
Reviewed-on: https://go-review.googlesource.com/c/go/+/724440
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
Change-Id: Iadfa2dd982d7156d60fb6977ed9afb7894d6e8a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/724321
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
This CL also fixed some documentation errors in existing APIs.
Go defaults MXCSR to mask exceptions, the documentation is based on this
fact.
Change-Id: I745083b82b4bef93126a4b4e41f8698956963704
Reviewed-on: https://go-review.googlesource.com/c/go/+/724320
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
|
|
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
add Fetcher.sumState mu sync.Mutex
ex {
goSum.mu -> Fetcher_.mu
goSum.m -> Fetcher_.sumState.m
goSum.w -> Fetcher_.sumState.w
goSum.status -> Fetcher_.sumState.status
goSum.overwrite -> Fetcher_.sumState.overwrite
goSum.enabled -> Fetcher_.sumState.enabled
goSum.sumState -> Fetcher_.sumState
}
rm goSum
'
Change-Id: I3693905d5bed19f7bae60f5bc1ec5097354c9427
Reviewed-on: https://go-review.googlesource.com/c/go/+/722582
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
This commit makes Unzip a method on the *Fetcher type, and updates
fips140 initialization to use a new Fetcher instance instead of the
global Fetcher_ variable.
Change-Id: Iea8d9ee4dd6e6a2be43520c144aaec6e75c9cd63
Reviewed-on: https://go-review.googlesource.com/c/go/+/722581
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
|
|
We update the RISC-V assembler documentation to describe how
the RISC-V compressed instruction set is implemented by the
assembler and how compressed instructions can be disabled.
Change-Id: Ic7b1cb1586e6906af78adb8ff5fa10f5fbfde292
Reviewed-on: https://go-review.googlesource.com/c/go/+/719221
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Auto-Submit: Joel Sing <joel@sing.id.au>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
|
|
This change renames the type State to Fetcher to better reflect its
purpose. The global variable ModuleFetchState is also renamed to
Fetcher_, which will continue to be gradually eliminated as with all
global state in the modfetch package.
[git-generate]
cd src/cmd/go/internal/modfetch
rf '
mv State Fetcher
mv ModuleFetchState Fetcher_
mv NewState NewFetcher
mv Fetcher.GoSumFile GoSumFile
mv GoSumFile.s GoSumFile.f
mv GoSumFile Fetcher.GoSumFile
mv Fetcher.SetGoSumFile SetGoSumFile
mv SetGoSumFile.s SetGoSumFile.f
mv SetGoSumFile Fetcher.SetGoSumFile
mv Fetcher.AddWorkspaceGoSumFile AddWorkspaceGoSumFile
mv AddWorkspaceGoSumFile.s AddWorkspaceGoSumFile.f
mv AddWorkspaceGoSumFile Fetcher.AddWorkspaceGoSumFile
'
rf '
add NewFetcher:+0 f := new(Fetcher) \
f.lookupCache = new(par.Cache[lookupCacheKey, Repo]) \
f.downloadCache = new(par.ErrCache[module.Version, string]) \
return f
'
rf 'rm NewFetcher:+5,8'
cd ../modload
rf '
mv State.modfetchState State.fetcher
'
Change-Id: I7cb6c945ea0f1d2119e1615064f041e88c81c689
Reviewed-on: https://go-review.googlesource.com/c/go/+/721740
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
