- 17 Oct, 2018 16 commits
-
-
Robert Griesemer authored
This change backports a minor modification of the x/tools version of this code back into the std library. It simply ensures that both versions of the code are the same and will simplify keeping them in sync down the road. While this is an API change, this is an internal package, so we're ok. Updates #27891. Change-Id: Ib153141382f727a2692ca80179ae09c4a383ba4f Reviewed-on: https://go-review.googlesource.com/c/142894Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
The spec currently provides a syntactic rule for receiver base types, and a strict reading of those rules prohibits the use of type aliases referring to pointer types as receiver types. This strict interpretation breaks an assumed rule for aliases, which is that a type literal can always be replaced by an alias denoting that literal. Furthermore, cmd/compile always accepted this new formulation of the receiver type rules and so this change will simply validate what has been implemented all along. Fixes #27995. Change-Id: I032289c926a4f070d6f7795431d86635fe64d907 Reviewed-on: https://go-review.googlesource.com/c/142757Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Ian Lance Taylor authored
Fixes #28169 Change-Id: I187d9effea56357bbb04d4971d284a52ffae61f8 Reviewed-on: https://go-review.googlesource.com/c/142889 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
This generates the same code as before, but does so directly rather than building an AST and printing that. This is in preparation for later changes. Change-Id: Ifec141120bcc74847f0bff8d3d47306bfe69b454 Reviewed-on: https://go-review.googlesource.com/c/142883 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
This is in preparation for later changes. Change-Id: I2b9b77a782cf65a2fcec5e700ec6bb8b1476f6b5 Reviewed-on: https://go-review.googlesource.com/c/142882 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Move name mangling before rewriting calls rather than after. This is in preparation for later changes. Change-Id: I74bc351f4290dad7ebf6d0d361bb684087786053 Reviewed-on: https://go-review.googlesource.com/c/142881 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jordan Rhee authored
Fixes #28182 Change-Id: I49c2117fba6325c234512f937ff2edfa9477f52f Reviewed-on: https://go-review.googlesource.com/c/142886Reviewed-by:
-
Matthew Dempsky authored
Nowadays there are better ways to safely run untrusted Go programs, like NaCl and gVisor. Change-Id: I20c45f13a50dbcf35c343438b720eb93e7b4e13a Reviewed-on: https://go-review.googlesource.com/c/142717 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
This appears to have simply been an oversight. Change-Id: Ia5d1309b3ebc99c9abbf0282397693272d8178aa Reviewed-on: https://go-review.googlesource.com/c/142885 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Michael Anthony Knyszek authored
Currently, mheap tracks spans in both mSpanLists and mTreaps, but mSpanLists, while they tend to be smaller, complicate the implementation. Here we simplify the implementation by removing free and busy from mheap and renaming freelarge -> free and busylarge -> busy. This change also slightly changes the reclamation policy. Previously, for allocations under 1MB we would attempt to find a small span of the right size. Now, we just try to find any number of spans totaling the right size. This may increase heap fragmentation, but that will be dealt with using virtual memory tricks in follow-up CLs. For #14045. Garbage-heavy benchmarks show very little change, except what appears to be a decrease in STW times and peak RSS. name old STW-ns/GC new STW-ns/GC delta Garbage/benchmem-MB=64-8 263k ±64% 217k ±24% -17.66% (p=0.028 n=25+23) name old STW-ns/op new STW-ns/op delta Garbage/benchmem-MB=64-8 9.39k ±65% 7.80k ±24% -16.88% (p=0.037 n=25+23) name old peak-RSS-bytes new peak-RSS-bytes delta Garbage/benchmem-MB=64-8 281M ± 0% 249M ± 4% -11.40% (p=0.000 n=19+18) https://perf.golang.org/search?q=upload:20181005.1 Go1 benchmarks perform roughly the same, the most notable regression being the JSON encode/decode benchmark with worsens by ~2%. name old time/op new time/op delta BinaryTree17-8 3.02s ± 2% 2.99s ± 2% -1.18% (p=0.000 n=25+24) Fannkuch11-8 3.05s ± 1% 3.02s ± 2% -1.20% (p=0.000 n=25+25) FmtFprintfEmpty-8 43.6ns ± 5% 43.4ns ± 3% ~ (p=0.528 n=25+25) FmtFprintfString-8 74.9ns ± 3% 73.4ns ± 1% -2.03% (p=0.001 n=25+24) FmtFprintfInt-8 79.3ns ± 3% 77.9ns ± 1% -1.73% (p=0.003 n=25+25) FmtFprintfIntInt-8 119ns ± 6% 116ns ± 0% -2.68% (p=0.000 n=25+18) FmtFprintfPrefixedInt-8 134ns ± 4% 132ns ± 1% -1.52% (p=0.004 n=25+25) FmtFprintfFloat-8 240ns ± 1% 241ns ± 1% ~ (p=0.403 n=24+23) FmtManyArgs-8 543ns ± 1% 537ns ± 1% -1.00% (p=0.000 n=25+25) GobDecode-8 6.88ms ± 1% 6.92ms ± 4% ~ (p=0.088 n=24+22) GobEncode-8 5.92ms ± 1% 5.93ms ± 1% ~ (p=0.898 n=25+24) Gzip-8 267ms ± 2% 266ms ± 2% ~ (p=0.213 n=25+24) Gunzip-8 35.4ms ± 1% 35.6ms ± 1% +0.70% (p=0.000 n=25+25) HTTPClientServer-8 104µs ± 2% 104µs ± 2% ~ (p=0.686 n=25+25) JSONEncode-8 9.67ms ± 1% 9.80ms ± 4% +1.32% (p=0.000 n=25+25) JSONDecode-8 47.7ms ± 1% 48.8ms ± 5% +2.33% (p=0.000 n=25+25) Mandelbrot200-8 4.87ms ± 1% 4.91ms ± 1% +0.79% (p=0.000 n=25+25) GoParse-8 3.59ms ± 4% 3.55ms ± 1% ~ (p=0.199 n=25+24) RegexpMatchEasy0_32-8 90.3ns ± 1% 89.9ns ± 1% -0.47% (p=0.000 n=25+21) RegexpMatchEasy0_1K-8 204ns ± 1% 204ns ± 1% ~ (p=0.914 n=25+24) RegexpMatchEasy1_32-8 84.9ns ± 0% 84.6ns ± 1% -0.36% (p=0.000 n=24+25) RegexpMatchEasy1_1K-8 350ns ± 1% 348ns ± 3% -0.59% (p=0.007 n=25+25) RegexpMatchMedium_32-8 122ns ± 1% 121ns ± 0% -1.08% (p=0.000 n=25+18) RegexpMatchMedium_1K-8 36.1µs ± 1% 34.6µs ± 1% -4.02% (p=0.000 n=25+25) RegexpMatchHard_32-8 1.69µs ± 2% 1.65µs ± 1% -2.38% (p=0.000 n=25+25) RegexpMatchHard_1K-8 50.8µs ± 1% 49.4µs ± 1% -2.69% (p=0.000 n=25+24) Revcomp-8 453ms ± 2% 449ms ± 3% -0.74% (p=0.022 n=25+24) Template-8 63.2ms ± 2% 63.4ms ± 1% ~ (p=0.127 n=25+24) TimeParse-8 313ns ± 1% 315ns ± 3% ~ (p=0.924 n=24+25) TimeFormat-8 294ns ± 1% 292ns ± 2% -0.65% (p=0.004 n=23+24) [Geo mean] 49.9µs 49.6µs -0.65% name old speed new speed delta GobDecode-8 112MB/s ± 1% 110MB/s ± 4% -1.00% (p=0.036 n=24+24) GobEncode-8 130MB/s ± 1% 129MB/s ± 1% ~ (p=0.894 n=25+24) Gzip-8 72.7MB/s ± 2% 73.0MB/s ± 2% ~ (p=0.208 n=25+24) Gunzip-8 549MB/s ± 1% 545MB/s ± 1% -0.70% (p=0.000 n=25+25) JSONEncode-8 201MB/s ± 1% 198MB/s ± 3% -1.29% (p=0.000 n=25+25) JSONDecode-8 40.7MB/s ± 1% 39.8MB/s ± 5% -2.23% (p=0.000 n=25+25) GoParse-8 16.2MB/s ± 4% 16.3MB/s ± 1% ~ (p=0.211 n=25+24) RegexpMatchEasy0_32-8 354MB/s ± 1% 356MB/s ± 1% +0.47% (p=0.000 n=25+21) RegexpMatchEasy0_1K-8 5.00GB/s ± 0% 4.99GB/s ± 1% ~ (p=0.588 n=24+24) RegexpMatchEasy1_32-8 377MB/s ± 1% 378MB/s ± 1% +0.39% (p=0.000 n=25+25) RegexpMatchEasy1_1K-8 2.92GB/s ± 1% 2.94GB/s ± 3% +0.65% (p=0.008 n=25+25) RegexpMatchMedium_32-8 8.14MB/s ± 1% 8.22MB/s ± 1% +0.98% (p=0.000 n=25+24) RegexpMatchMedium_1K-8 28.4MB/s ± 1% 29.6MB/s ± 1% +4.19% (p=0.000 n=25+25) RegexpMatchHard_32-8 18.9MB/s ± 2% 19.4MB/s ± 1% +2.43% (p=0.000 n=25+25) RegexpMatchHard_1K-8 20.2MB/s ± 1% 20.7MB/s ± 1% +2.76% (p=0.000 n=25+24) Revcomp-8 561MB/s ± 2% 566MB/s ± 3% +0.75% (p=0.021 n=25+24) Template-8 30.7MB/s ± 2% 30.6MB/s ± 1% ~ (p=0.131 n=25+24) [Geo mean] 120MB/s 121MB/s +0.48% https://perf.golang.org/search?q=upload:20181004.6 Change-Id: I97f9fee34577961a116a8ddd445c6272253f0f95 Reviewed-on: https://go-review.googlesource.com/c/139837 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Michael Anthony Knyszek authored
Currently, span scavenging was done nearly identically in two different locations. This change deduplicates that into one shared routine. For #14045. Change-Id: I15006b2c9af0e70b7a9eae9abb4168d3adca3860 Reviewed-on: https://go-review.googlesource.com/c/139297 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Yury Smolsky authored
Too deeply nested code is hard to fit in ssa.html. This CL reduces the tab size to 4 characters. Change-Id: I08643b0868bce3439567084c7d701654655f23d7 Reviewed-on: https://go-review.googlesource.com/c/142857Reviewed-by:
David Chase <drchase@google.com>
-
Rob Pike authored
One too many lines was deleted, and it would print a header multiple times. Add a test. Change-Id: I4906b454dbb66193d515ffacf43849ffdc2dede6 Reviewed-on: https://go-review.googlesource.com/c/142937Reviewed-by:
Ralph Corderoy <ralph@inputplus.co.uk> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Pike authored
Unlike the one for the old godoc, you need the -u flag to see unexported symbols. This seems like the right behavior: it's consistent. For now at least, the argument must be a package, not a symbol. This is also different from old godoc. Required a little refactoring but also cleaned up a few things. Update #25595 Leaving the bug open for now until we tackle go doc -all symbol Change-Id: Ibc1975bfa592cb1e92513eb2e5e9e11e01a60095 Reviewed-on: https://go-review.googlesource.com/c/141977 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
Use the format "RFC XXXX, Section X.X" (or "Appendix Y.X") as it fits more properly in prose than a link, is more future-proof, and as there are multiple ways to render an RFC. Capital "S" to follow the quoting standard of RFCs themselves. Applied the new goimports grouping to all files in those packages, too. Change-Id: I01267bb3a3b02664f8f822e97b129075bb14d404 Reviewed-on: https://go-review.googlesource.com/c/141918Reviewed-by:
Dmitri Shuralyov <dmitshur@golang.org>
-
Rijnard van Tonder authored
Change-Id: I8cc4b5efe798e74b6daabd64fc2dd5486dcb7c5e GitHub-Last-Rev: 694509e33df7c5729ec0bf7b053ff18ebd87c36b GitHub-Pull-Request: golang/go#28115 Reviewed-on: https://go-review.googlesource.com/c/140998 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 16 Oct, 2018 11 commits
-
-
Robert Griesemer authored
Follow-up on https://golang.org/cl/124595; no semantic changes. Updates #26411. Change-Id: Ic1c4622dbf79529ff61530f9c25ec742c2abe5ca Reviewed-on: https://go-review.googlesource.com/c/142720 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel T Odeke authored
Ensure that label redefinition error column numbers print the actual start of the label instead of the position of the label's delimiting token ":". For example, given this program: package main func main() { foo: foo: foo: foo : } * Before: main.go:5:13: label foo defined and not used main.go:6:7: label foo already defined at main.go:5:13 main.go:7:4: label foo already defined at main.go:5:13 main.go:8:16: label foo already defined at main.go:5:13 * After: main.go:5:13: label foo defined and not used main.go:6:4: label foo already defined at main.go:5:13 main.go:7:1: label foo already defined at main.go:5:13 main.go:8:1: label foo already defined at main.go:5:13 Fixes #26411 Change-Id: I8eb874b97fdc8862547176d57ac2fa0f075f2367 Reviewed-on: https://go-review.googlesource.com/c/124595 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Robert Griesemer <gri@golang.org>
-
Ilya Tocar authored
Currently all inlining of autogenerated wrappers is disabled, because it causes build failures, when indexed export format is enabled. Turns out we can reenable it for common case of (*T).M wrappers. This fixes most performance degradation of 1.11 vs 1.10. encoding/binary: name old time/op new time/op delta ReadSlice1000Int32s-6 14.8µs ± 2% 11.5µs ± 2% -22.01% (p=0.000 n=10+10) WriteSlice1000Int32s-6 14.8µs ± 2% 11.7µs ± 2% -20.95% (p=0.000 n=10+10) bufio: name old time/op new time/op delta WriterFlush-6 32.4ns ± 1% 28.8ns ± 0% -11.17% (p=0.000 n=9+10) sort: SearchWrappers-6 231ns ± 1% 231ns ± 0% ~ (p=0.129 n=9+10) SortString1K-6 365µs ± 1% 298µs ± 1% -18.43% (p=0.000 n=9+10) SortString1K_Slice-6 274µs ± 2% 276µs ± 1% ~ (p=0.105 n=10+10) StableString1K-6 490µs ± 1% 373µs ± 1% -23.73% (p=0.000 n=10+10) SortInt1K-6 210µs ± 1% 142µs ± 1% -32.69% (p=0.000 n=10+10) StableInt1K-6 243µs ± 0% 151µs ± 1% -37.75% (p=0.000 n=10+10) StableInt1K_Slice-6 130µs ± 1% 130µs ± 0% ~ (p=0.237 n=10+8) SortInt64K-6 19.9ms ± 1% 13.5ms ± 1% -32.32% (p=0.000 n=10+10) SortInt64K_Slice-6 11.5ms ± 1% 11.5ms ± 1% ~ (p=0.912 n=10+10) StableInt64K-6 21.5ms ± 0% 13.5ms ± 1% -37.30% (p=0.000 n=9+10) Sort1e2-6 108µs ± 2% 83µs ± 3% -23.26% (p=0.000 n=10+10) Stable1e2-6 218µs ± 0% 161µs ± 1% -25.99% (p=0.000 n=8+9) Sort1e4-6 22.6ms ± 1% 16.8ms ± 0% -25.45% (p=0.000 n=10+7) Stable1e4-6 67.6ms ± 1% 49.7ms ± 0% -26.48% (p=0.000 n=10+10) Sort1e6-6 3.44s ± 0% 2.55s ± 1% -26.05% (p=0.000 n=8+9) Stable1e6-6 13.7s ± 0% 9.9s ± 1% -27.68% (p=0.000 n=8+10) Fixes #27621 Updates #25338 Change-Id: I6fe633202f63fa829a6ab849c44d7e45f8835dff Reviewed-on: https://go-review.googlesource.com/c/135697 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
Numbers without decimals are valid Go representations of whole-number floats. That is, "var x float64 = 5" is valid Go. Avoid breakage in tests that expect a certain output from %#v by reverting to it. To guarantee the right type is generated by a print use %T(%#v) instead. Added a test to lock in this behavior. This reverts commit 7c7cecc1. Fixes #27634 Updates #26363 Change-Id: I544c400a0903777dd216452a7e86dfe60b0b0283 Reviewed-on: https://go-review.googlesource.com/c/142597 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Bryan C. Mills <bcmills@google.com>
-
Matthew Dempsky authored
This used to be used by cmd/vet and some assembly generation tests, but those were removed in CL 37691 and CL 107336. No point in keeping an unneeded flag around. Fixes #28220. Change-Id: I59f8546954ab36ea61ceba81c10d6e16d74b966a Reviewed-on: https://go-review.googlesource.com/c/142677 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
There are only a handful of nodes that we need to pass to typecheckdef (OLITERAL, ONAME, OTYPE, and ONONAME), but typecheck1 takes the awkward approach of calling typecheckdef on every node with Sym != nil, and then excluding a long list of uninteresting Ops that have a non-nil Sym. Passes toolstash-check. Change-Id: I0271d2faff0208ad57ddc1f1a540a5fbed870234 Reviewed-on: https://go-review.googlesource.com/c/142657 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lynn Boger authored
Adding cases for ppc64,ppc64le to the codegen tests where appropriate. Change-Id: Idf8cbe88a4ab4406a4ef1ea777bd15a58b68f3ed Reviewed-on: https://go-review.googlesource.com/c/142557 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
Calling .Interface on a struct field's reflect.Value isn't always safe. For example, if that field is an unexported anonymous struct. We only descended into this branch if the struct type had any methods, so this bug had gone unnoticed for a few release cycles. Add the check, and add a simple test case. Fixes #28145. Change-Id: I02f7e0ab9a4a0c18a5e2164211922fe9c3d30f64 Reviewed-on: https://go-review.googlesource.com/c/141537 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
Given a program as follows: data := []byte(`{"F": { "a": 2, "3": 4 }}`) json.Unmarshal(data, &map[string]map[int]int{}) The JSON package should error, as "a" is not a valid integer. However, we'd encounter a panic: panic: JSON decoder out of sync - data changing underfoot? The reason was that decodeState.object would return a nil error on encountering the invalid map key string, while saving the key type error for later. This broke if we were inside another object, as we would abruptly end parsing the nested object, leaving the decoder in an unexpected state. To fix this, simply avoid storing the map element and continue decoding the object, to leave the decoder state exactly as if we hadn't seen an invalid key type. This affected both signed and unsigned integer keys, so fix both and add two test cases. Updates #28189. Change-Id: I8a6204cc3ff9fb04ed769df7a20a824c8b94faff Reviewed-on: https://go-review.googlesource.com/c/142518Reviewed-by: -
Ben Shi authored
This CL adds more combinations of two consequtive MOVBload/MOVBstore to a unique MOVWload/MOVWstore. 1. The size of the go executable decreases about 4KB, and the total size of pkg/linux_386 (excluding cmd/compile) decreases about 1.5KB. 2. There is no regression in the go1 benchmark result, excluding noise. name old time/op new time/op delta BinaryTree17-4 3.28s ± 2% 3.29s ± 2% ~ (p=0.151 n=40+40) Fannkuch11-4 3.52s ± 1% 3.51s ± 1% -0.28% (p=0.002 n=40+40) FmtFprintfEmpty-4 45.4ns ± 4% 45.0ns ± 4% -0.89% (p=0.019 n=40+40) FmtFprintfString-4 81.9ns ± 7% 81.3ns ± 1% ~ (p=0.660 n=40+25) FmtFprintfInt-4 91.9ns ± 9% 91.4ns ± 9% ~ (p=0.249 n=40+40) FmtFprintfIntInt-4 143ns ± 4% 143ns ± 4% ~ (p=0.760 n=40+40) FmtFprintfPrefixedInt-4 184ns ± 3% 183ns ± 4% ~ (p=0.485 n=40+40) FmtFprintfFloat-4 408ns ± 3% 409ns ± 3% ~ (p=0.961 n=40+40) FmtManyArgs-4 597ns ± 4% 602ns ± 3% ~ (p=0.413 n=40+40) GobDecode-4 7.13ms ± 6% 7.14ms ± 6% ~ (p=0.859 n=40+40) GobEncode-4 6.86ms ± 9% 6.94ms ± 7% ~ (p=0.162 n=40+40) Gzip-4 395ms ± 4% 396ms ± 3% ~ (p=0.099 n=40+40) Gunzip-4 40.9ms ± 4% 41.1ms ± 3% ~ (p=0.064 n=40+40) HTTPClientServer-4 63.6µs ± 2% 63.6µs ± 3% ~ (p=0.832 n=36+39) JSONEncode-4 16.1ms ± 3% 15.8ms ± 3% -1.60% (p=0.001 n=40+40) JSONDecode-4 61.0ms ± 3% 61.5ms ± 4% ~ (p=0.065 n=40+40) Mandelbrot200-4 5.16ms ± 3% 5.18ms ± 3% ~ (p=0.056 n=40+40) GoParse-4 3.25ms ± 2% 3.23ms ± 3% ~ (p=0.727 n=40+40) RegexpMatchEasy0_32-4 90.2ns ± 3% 89.3ns ± 6% -0.98% (p=0.002 n=40+40) RegexpMatchEasy0_1K-4 812ns ± 3% 815ns ± 3% ~ (p=0.309 n=40+40) RegexpMatchEasy1_32-4 103ns ± 6% 103ns ± 5% ~ (p=0.680 n=40+40) RegexpMatchEasy1_1K-4 1.01µs ± 4% 1.02µs ± 3% ~ (p=0.326 n=40+33) RegexpMatchMedium_32-4 120ns ± 4% 120ns ± 5% ~ (p=0.834 n=40+40) RegexpMatchMedium_1K-4 40.1µs ± 3% 39.5µs ± 4% -1.35% (p=0.000 n=40+40) RegexpMatchHard_32-4 2.27µs ± 6% 2.23µs ± 4% -1.67% (p=0.011 n=40+40) RegexpMatchHard_1K-4 67.2µs ± 3% 67.2µs ± 3% ~ (p=0.149 n=40+40) Revcomp-4 1.84s ± 2% 1.86s ± 3% +0.70% (p=0.020 n=40+40) Template-4 69.0ms ± 4% 69.8ms ± 3% +1.20% (p=0.003 n=40+40) TimeParse-4 438ns ± 3% 439ns ± 4% ~ (p=0.650 n=40+40) TimeFormat-4 412ns ± 3% 412ns ± 3% ~ (p=0.888 n=40+40) [Geo mean] 65.2µs 65.2µs -0.04% name old speed new speed delta GobDecode-4 108MB/s ± 6% 108MB/s ± 6% ~ (p=0.855 n=40+40) GobEncode-4 112MB/s ± 9% 111MB/s ± 8% ~ (p=0.159 n=40+40) Gzip-4 49.2MB/s ± 4% 49.1MB/s ± 3% ~ (p=0.102 n=40+40) Gunzip-4 474MB/s ± 3% 472MB/s ± 3% ~ (p=0.063 n=40+40) JSONEncode-4 121MB/s ± 3% 123MB/s ± 3% +1.62% (p=0.001 n=40+40) JSONDecode-4 31.9MB/s ± 3% 31.6MB/s ± 4% ~ (p=0.070 n=40+40) GoParse-4 17.9MB/s ± 2% 17.9MB/s ± 3% ~ (p=0.696 n=40+40) RegexpMatchEasy0_32-4 355MB/s ± 3% 358MB/s ± 5% +0.99% (p=0.002 n=40+40) RegexpMatchEasy0_1K-4 1.26GB/s ± 3% 1.26GB/s ± 3% ~ (p=0.381 n=40+40) RegexpMatchEasy1_32-4 310MB/s ± 5% 310MB/s ± 4% ~ (p=0.655 n=40+40) RegexpMatchEasy1_1K-4 1.01GB/s ± 4% 1.01GB/s ± 3% ~ (p=0.351 n=40+33) RegexpMatchMedium_32-4 8.32MB/s ± 4% 8.34MB/s ± 5% ~ (p=0.696 n=40+40) RegexpMatchMedium_1K-4 25.6MB/s ± 3% 25.9MB/s ± 4% +1.36% (p=0.000 n=40+40) RegexpMatchHard_32-4 14.1MB/s ± 6% 14.3MB/s ± 4% +1.64% (p=0.011 n=40+40) RegexpMatchHard_1K-4 15.2MB/s ± 3% 15.2MB/s ± 3% ~ (p=0.147 n=40+40) Revcomp-4 138MB/s ± 2% 137MB/s ± 3% -0.70% (p=0.021 n=40+40) Template-4 28.1MB/s ± 4% 27.8MB/s ± 3% -1.19% (p=0.003 n=40+40) [Geo mean] 83.7MB/s 83.7MB/s +0.03% Change-Id: I2a2b3a942b5c45467491515d201179fd192e65c9 Reviewed-on: https://go-review.googlesource.com/c/141650 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Ben Shi authored
ARMv7's MULAF/MULSF/MULAD/MULSD are not fused, this CL fixes the confusing test cases. Change-Id: I35022e207e2f0d24a23a7f6f188e41ba8eee9886 Reviewed-on: https://go-review.googlesource.com/c/142439 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Akhil Indurti <aindurti@gmail.com> Reviewed-by:
Giovanni Bajo <rasky@develer.com>
-
- 15 Oct, 2018 13 commits
-
-
Daniel Martí authored
In golang.org/cl/75310, the compiler's typechecker was changed so that map key types were validated at a later stage, to make sure that all the necessary type information was present. This still worked for map type declarations, but caused a regression for top-level map variable declarations. These now caused a fatal panic instead of a typechecking error. The cause was that checkMapKeys was run too early, before all typechecking was done. In particular, top-level map variable declarations are typechecked as external declarations, much later than where checkMapKeys was run. Add a test case for both exported and unexported top-level map declarations, and add a second call to checkMapKeys at the actual end of typechecking. Simply moving the one call isn't a good solution either; the comments expand on that. Fixes #28058. Change-Id: Ia5febb01a1d877447cf66ba44fb49a7e0f4f18a5 Reviewed-on: https://go-review.googlesource.com/c/140417 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
This CL adds the ability to enable the cpu feature FEATURE by specifying FEATURE=on in GODEBUGCPU. Syntax support to enable cpu features is useful in combination with a preceeding all=off to disable all but some specific cpu features. Example: GODEBUGCPU=all=off,sse3=on This CL implements printing of warnings for invalid GODEBUGCPU settings: - requests enabling features that are not supported with the current CPU - specifying values different than 'on' or 'off' for a feature - settings for unkown cpu feature names Updates #27218 Change-Id: Ic13e5c4c35426a390c50eaa4bd2a408ef2ee21be Reviewed-on: https://go-review.googlesource.com/c/141800 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
The compiler can generate better code for shifts bounded to be less than 32 and thereby known to be less than any register width. See https://golang.org/cl/109776. Change-Id: I0c4c9f0faafa065fce3c10fd328830deb92f9e38 Reviewed-on: https://go-review.googlesource.com/c/111735 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
x = map[string(byteslice)] is already optimized by the compiler to avoid a string allocation. This CL generalizes this optimization to: x = map[T1{ ... Tn{..., string(byteslice), ...} ... }] where T1 to Tn is a nesting of struct and array literals. Found in a hot code path that used a struct of strings made from []byte slices to make a map lookup. There are no uses of the more generalized optimization in the standard library. Passes toolstash -cmp. MapStringConversion/32/simple 21.9ns ± 2% 21.9ns ± 3% ~ (p=0.995 n=17+20) MapStringConversion/32/struct 28.8ns ± 3% 22.0ns ± 2% -23.80% (p=0.000 n=20+20) MapStringConversion/32/array 28.5ns ± 2% 21.9ns ± 2% -23.14% (p=0.000 n=19+16) MapStringConversion/64/simple 21.0ns ± 2% 21.1ns ± 3% ~ (p=0.072 n=19+18) MapStringConversion/64/struct 72.4ns ± 3% 21.3ns ± 2% -70.53% (p=0.000 n=20+20) MapStringConversion/64/array 72.8ns ± 1% 21.0ns ± 2% -71.13% (p=0.000 n=17+19) name old allocs/op new allocs/op delta MapStringConversion/32/simple 0.00 0.00 ~ (all equal) MapStringConversion/32/struct 0.00 0.00 ~ (all equal) MapStringConversion/32/array 0.00 0.00 ~ (all equal) MapStringConversion/64/simple 0.00 0.00 ~ (all equal) MapStringConversion/64/struct 1.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20) MapStringConversion/64/array 1.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20) Change-Id: I483b4d84d8d74b1025b62c954da9a365e79b7a3a Reviewed-on: https://go-review.googlesource.com/c/116275Reviewed-by: -
Martin Möhrmann authored
Add generic, 386 and amd64 specific ops and SSA rules for multiplication with overflow and branching based on overflow flags. Use these to intrinsify runtime/internal/math.MulUinptr. On amd64 mul, overflow := math.MulUintptr(a, b) if overflow { is lowered to two instructions: MULQ SI JO 0x10ee35c No codegen tests as codegen can not currently test unexported internal runtime functions. amd64: name old time/op new time/op delta MulUintptr/small 1.16ns ± 5% 0.88ns ± 6% -24.36% (p=0.000 n=19+20) MulUintptr/large 10.7ns ± 1% 1.1ns ± 1% -89.28% (p=0.000 n=17+19) Change-Id: If60739a86f820e5044d677276c21df90d3c7a86a Reviewed-on: https://go-review.googlesource.com/c/141820 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Martin Möhrmann authored
The generated code for the append builtin already checks if the appended to slice is large enough and calls growslice if that is not the case. Trust that this ensures the slice is large enough and avoid the implicit bounds check when slicing the slice to its new size. Removes 365 panicslice calls (-14%) from the go binary which reduces the binary size by ~12kbyte. Change-Id: I1b88418675ff409bc0b956853c9e95241274d5a6 Reviewed-on: https://go-review.googlesource.com/c/119315 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
This CL adds a new internal math package for use by the runtime. The new package exports a MulUintptr function with uintptr arguments a and b and returns uintptr(a*b) and whether the full-width product x*y does overflow the uintptr value range (uintptr(x*y) != x*y). Uses of MulUinptr in the runtime and intrinsics for performance will be added in followup CLs. Updates #21588 Change-Id: Ia5a02eeabc955249118e4edf68c67d9fc0858058 Reviewed-on: https://go-review.googlesource.com/c/91755 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Followon from CL 140306 Change-Id: Ic71033d2301105b15b60645d895a076107f44a2e Reviewed-on: https://go-review.googlesource.com/c/142178 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Alberto Donizetti authored
This change adds codegen tests for the intrinsification on ppc64 of the OnesCount{64,32,16,8}, and TrailingZeros{64,32,16,8} math/bits functions. Change-Id: Id3364921fbd18316850e15c8c71330c906187fdb Reviewed-on: https://go-review.googlesource.com/c/141897Reviewed-by:Lynn Boger <laboger@linux.vnet.ibm.com>
-
Josh Bleecher Snyder authored
The branchelim pass works better after fuse. Running fuse before branchelim also increases the stability of generated code amidst other compiler changes, which was the original motivation behind this change. The fuse pass is not cheap enough to run in its entirety before branchelim, but the most important half of it is. This change makes it possible to run "plain fuse" independently and does so before branchelim. During make.bash, elimIf occurrences increase from 4244 to 4288 (1%), and elimIfElse occurrences increase from 989 to 1079 (9%). Toolspeed impact is marginal; plain fuse pays for itself. name old time/op new time/op delta Template 189ms ± 2% 189ms ± 2% ~ (p=0.890 n=45+46) Unicode 93.2ms ± 5% 93.4ms ± 7% ~ (p=0.790 n=48+48) GoTypes 662ms ± 4% 660ms ± 4% ~ (p=0.186 n=48+49) Compiler 2.89s ± 4% 2.91s ± 3% +0.89% (p=0.050 n=49+44) SSA 8.23s ± 2% 8.21s ± 1% ~ (p=0.165 n=46+44) Flate 123ms ± 4% 123ms ± 3% +0.58% (p=0.031 n=47+49) GoParser 154ms ± 4% 154ms ± 4% ~ (p=0.492 n=49+48) Reflect 430ms ± 4% 429ms ± 4% ~ (p=1.000 n=48+48) Tar 171ms ± 3% 170ms ± 4% ~ (p=0.122 n=48+48) XML 232ms ± 3% 232ms ± 2% ~ (p=0.850 n=46+49) [Geo mean] 394ms 394ms +0.02% name old user-time/op new user-time/op delta Template 236ms ± 5% 236ms ± 4% ~ (p=0.934 n=50+50) Unicode 132ms ± 7% 130ms ± 9% ~ (p=0.087 n=50+50) GoTypes 861ms ± 3% 867ms ± 4% ~ (p=0.124 n=48+50) Compiler 3.93s ± 4% 3.94s ± 3% ~ (p=0.584 n=49+44) SSA 12.2s ± 2% 12.3s ± 1% ~ (p=0.610 n=46+45) Flate 149ms ± 4% 150ms ± 4% ~ (p=0.194 n=48+49) GoParser 193ms ± 5% 191ms ± 6% ~ (p=0.239 n=49+50) Reflect 553ms ± 5% 556ms ± 5% ~ (p=0.091 n=49+49) Tar 218ms ± 5% 218ms ± 5% ~ (p=0.359 n=49+50) XML 299ms ± 5% 298ms ± 4% ~ (p=0.482 n=50+49) [Geo mean] 516ms 516ms -0.01% name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.3MB ± 0% -0.02% (p=0.000 n=49+49) Unicode 29.7MB ± 0% 29.7MB ± 0% ~ (p=0.270 n=50+50) GoTypes 126MB ± 0% 126MB ± 0% -0.34% (p=0.000 n=50+49) Compiler 534MB ± 0% 531MB ± 0% -0.50% (p=0.000 n=50+50) SSA 1.98GB ± 0% 1.98GB ± 0% -0.06% (p=0.000 n=49+49) Flate 24.6MB ± 0% 24.6MB ± 0% -0.29% (p=0.000 n=50+50) GoParser 29.5MB ± 0% 29.4MB ± 0% -0.15% (p=0.000 n=49+50) Reflect 87.3MB ± 0% 87.2MB ± 0% -0.13% (p=0.000 n=49+50) Tar 35.6MB ± 0% 35.5MB ± 0% -0.17% (p=0.000 n=50+50) XML 48.2MB ± 0% 48.0MB ± 0% -0.30% (p=0.000 n=48+50) [Geo mean] 83.1MB 82.9MB -0.20% name old allocs/op new allocs/op delta Template 352k ± 0% 352k ± 0% -0.01% (p=0.004 n=49+49) Unicode 341k ± 0% 341k ± 0% ~ (p=0.341 n=48+50) GoTypes 1.28M ± 0% 1.28M ± 0% -0.03% (p=0.000 n=50+49) Compiler 4.96M ± 0% 4.96M ± 0% -0.05% (p=0.000 n=50+49) SSA 15.5M ± 0% 15.5M ± 0% -0.01% (p=0.000 n=50+49) Flate 233k ± 0% 233k ± 0% +0.01% (p=0.032 n=49+49) GoParser 294k ± 0% 294k ± 0% ~ (p=0.052 n=46+48) Reflect 1.04M ± 0% 1.04M ± 0% ~ (p=0.171 n=50+47) Tar 343k ± 0% 343k ± 0% -0.03% (p=0.000 n=50+50) XML 429k ± 0% 429k ± 0% -0.04% (p=0.000 n=50+50) [Geo mean] 812k 812k -0.02% Object files grow slightly; branchelim often increases binary size, at least on amd64. name old object-bytes new object-bytes delta Template 509kB ± 0% 509kB ± 0% -0.01% (p=0.008 n=5+5) Unicode 224kB ± 0% 224kB ± 0% ~ (all equal) GoTypes 1.84MB ± 0% 1.84MB ± 0% +0.00% (p=0.008 n=5+5) Compiler 6.71MB ± 0% 6.71MB ± 0% +0.01% (p=0.008 n=5+5) SSA 21.2MB ± 0% 21.2MB ± 0% +0.01% (p=0.008 n=5+5) Flate 324kB ± 0% 324kB ± 0% -0.00% (p=0.008 n=5+5) GoParser 404kB ± 0% 404kB ± 0% -0.02% (p=0.008 n=5+5) Reflect 1.40MB ± 0% 1.40MB ± 0% +0.09% (p=0.008 n=5+5) Tar 452kB ± 0% 452kB ± 0% +0.06% (p=0.008 n=5+5) XML 596kB ± 0% 596kB ± 0% +0.00% (p=0.008 n=5+5) [Geo mean] 1.04MB 1.04MB +0.01% Change-Id: I535c711b85380ff657fc0f022bebd9cb14ddd07f Reviewed-on: https://go-review.googlesource.com/c/129378 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Ensure that we correctly type the stack temps for regular closures, method function closures, and slice literals. Then we don't need to override the dummy types later. Furthermore, this allows order to reuse temporaries of these types. OARRAYLIT doesn't need a temporary as far as I can tell, so I removed that case from order. Change-Id: Ic58520fa50c90639393ff78f33d3c831d5c4acb9 Reviewed-on: https://go-review.googlesource.com/c/140306Reviewed-by:
-
Keith Randall authored
Not sure why this changed behavior, but seems mostly harmless. Fixes #28198 Change-Id: Ie25c6e1fcb64912a582c7ae7bf92c4c1642e83cb Reviewed-on: https://go-review.googlesource.com/c/141649Reviewed-by:
-
Ben Shi authored
This CL adds tests of fused multiplication-accumulation on arm/arm64. Change-Id: Ic85d5277c0d6acb7e1e723653372dfaf96824a39 Reviewed-on: https://go-review.googlesource.com/c/141652 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
