- 06 Nov, 2018 1 commit
-
-
Josh Bleecher Snyder authored
convT2E16 and other specialized type-to-interface routines accept a type/itab argument and return a complete interface value. However, we know enough in the routine to do without the type. And the caller can construct the interface value using the type. Doing so shrinks the call sites of ten of the specialized convT2x routines. It also lets us unify the empty and non-empty interface routines. Cuts 12k off cmd/go. name old time/op new time/op delta ConvT2ESmall-8 2.96ns ± 2% 2.34ns ± 4% -21.01% (p=0.000 n=175+189) ConvT2EUintptr-8 3.00ns ± 3% 2.34ns ± 4% -22.02% (p=0.000 n=189+187) ConvT2ELarge-8 21.3ns ± 7% 21.5ns ± 5% +1.02% (p=0.000 n=200+197) ConvT2ISmall-8 2.99ns ± 4% 2.33ns ± 3% -21.95% (p=0.000 n=193+184) ConvT2IUintptr-8 3.02ns ± 3% 2.33ns ± 3% -22.82% (p=0.000 n=198+190) ConvT2ILarge-8 21.7ns ± 5% 22.2ns ± 4% +2.31% (p=0.000 n=199+198) ConvT2Ezero/zero/16-8 2.96ns ± 2% 2.33ns ± 3% -21.11% (p=0.000 n=174+187) ConvT2Ezero/zero/32-8 2.96ns ± 1% 2.35ns ± 4% -20.62% (p=0.000 n=163+193) ConvT2Ezero/zero/64-8 2.99ns ± 2% 2.34ns ± 4% -21.78% (p=0.000 n=183+188) ConvT2Ezero/zero/str-8 3.27ns ± 3% 2.54ns ± 3% -22.32% (p=0.000 n=195+192) ConvT2Ezero/zero/slice-8 3.46ns ± 4% 2.81ns ± 3% -18.96% (p=0.000 n=197+164) ConvT2Ezero/zero/big-8 88.4ns ±20% 90.0ns ±20% +1.84% (p=0.000 n=196+198) ConvT2Ezero/nonzero/16-8 12.6ns ± 3% 12.3ns ± 3% -2.34% (p=0.000 n=167+196) ConvT2Ezero/nonzero/32-8 12.3ns ± 4% 11.9ns ± 3% -2.95% (p=0.000 n=187+193) ConvT2Ezero/nonzero/64-8 14.2ns ± 6% 13.8ns ± 5% -2.94% (p=0.000 n=198+199) ConvT2Ezero/nonzero/str-8 27.2ns ± 5% 26.8ns ± 5% -1.33% (p=0.000 n=200+198) ConvT2Ezero/nonzero/slice-8 33.3ns ± 8% 33.1ns ± 6% -0.82% (p=0.000 n=199+200) ConvT2Ezero/nonzero/big-8 88.8ns ±22% 90.2ns ±18% +1.58% (p=0.000 n=200+199) Neligible toolspeed impact. name old alloc/op new alloc/op delta Template 35.4MB ± 0% 35.3MB ± 0% -0.06% (p=0.008 n=5+5) Unicode 29.1MB ± 0% 29.1MB ± 0% ~ (p=0.310 n=5+5) GoTypes 122MB ± 0% 122MB ± 0% -0.08% (p=0.008 n=5+5) Compiler 514MB ± 0% 513MB ± 0% -0.02% (p=0.008 n=5+5) SSA 1.94GB ± 0% 1.94GB ± 0% -0.01% (p=0.008 n=5+5) Flate 24.2MB ± 0% 24.2MB ± 0% ~ (p=0.548 n=5+5) GoParser 28.5MB ± 0% 28.5MB ± 0% -0.05% (p=0.016 n=5+5) Reflect 86.3MB ± 0% 86.2MB ± 0% -0.02% (p=0.008 n=5+5) Tar 34.9MB ± 0% 34.9MB ± 0% ~ (p=0.095 n=5+5) XML 47.1MB ± 0% 47.1MB ± 0% -0.05% (p=0.008 n=5+5) [Geo mean] 81.0MB 81.0MB -0.03% name old allocs/op new allocs/op delta Template 349k ± 0% 349k ± 0% -0.08% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% ~ (p=0.111 n=5+5) GoTypes 1.28M ± 0% 1.28M ± 0% -0.09% (p=0.008 n=5+5) Compiler 4.92M ± 0% 4.92M ± 0% -0.08% (p=0.008 n=5+5) SSA 15.3M ± 0% 15.3M ± 0% -0.03% (p=0.008 n=5+5) Flate 233k ± 0% 233k ± 0% ~ (p=0.500 n=5+5) GoParser 292k ± 0% 292k ± 0% -0.06% (p=0.008 n=5+5) Reflect 1.05M ± 0% 1.05M ± 0% -0.02% (p=0.008 n=5+5) Tar 344k ± 0% 343k ± 0% -0.06% (p=0.008 n=5+5) XML 430k ± 0% 429k ± 0% -0.08% (p=0.008 n=5+5) [Geo mean] 809k 809k -0.05% name old object-bytes new object-bytes delta Template 507kB ± 0% 507kB ± 0% -0.04% (p=0.008 n=5+5) Unicode 225kB ± 0% 225kB ± 0% ~ (all equal) GoTypes 1.85MB ± 0% 1.85MB ± 0% -0.08% (p=0.008 n=5+5) Compiler 6.75MB ± 0% 6.75MB ± 0% +0.01% (p=0.008 n=5+5) SSA 21.4MB ± 0% 21.4MB ± 0% -0.02% (p=0.008 n=5+5) Flate 328kB ± 0% 328kB ± 0% -0.03% (p=0.008 n=5+5) GoParser 403kB ± 0% 402kB ± 0% -0.06% (p=0.008 n=5+5) Reflect 1.41MB ± 0% 1.41MB ± 0% -0.03% (p=0.008 n=5+5) Tar 457kB ± 0% 457kB ± 0% -0.05% (p=0.008 n=5+5) XML 601kB ± 0% 600kB ± 0% -0.16% (p=0.008 n=5+5) [Geo mean] 1.05MB 1.04MB -0.05% Change-Id: I677a4108c0ecd32617549294036aa84f9214c4fe Reviewed-on: https://go-review.googlesource.com/c/147360 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
-
- 05 Nov, 2018 21 commits
-
-
Josh Bleecher Snyder authored
Consider these functions: func f(a any) int func g(a any) int Prior to this change, since f and g have identical signatures, they would share a single generated func type. types.SubstAny makes a shallow type copy, even after instantiation, f and g share a single generated Result type. So if you instantiate f with any=T, call dowidth, instantiate g with any=U, and call dowidth, and if sizeof(T) != sizeof(U), then the Offset of the result for f is now wrong. I don't believe this happens at all right now, but it bit me hard when experimenting with some other compiler changes. And it's hard to debug. It results in rare stack corruption, causing problems far from the actual source of the problem. To fix this, change SubstAny to make deep copies of TSTRUCTs. name old alloc/op new alloc/op delta Template 35.3MB ± 0% 35.4MB ± 0% +0.23% (p=0.008 n=5+5) Unicode 29.1MB ± 0% 29.1MB ± 0% +0.16% (p=0.008 n=5+5) GoTypes 122MB ± 0% 122MB ± 0% +0.16% (p=0.008 n=5+5) Compiler 513MB ± 0% 514MB ± 0% +0.19% (p=0.008 n=5+5) SSA 1.94GB ± 0% 1.94GB ± 0% +0.01% (p=0.008 n=5+5) Flate 24.2MB ± 0% 24.2MB ± 0% +0.08% (p=0.008 n=5+5) GoParser 28.5MB ± 0% 28.5MB ± 0% +0.24% (p=0.008 n=5+5) Reflect 86.2MB ± 0% 86.3MB ± 0% +0.09% (p=0.008 n=5+5) Tar 34.9MB ± 0% 34.9MB ± 0% +0.13% (p=0.008 n=5+5) XML 47.0MB ± 0% 47.1MB ± 0% +0.18% (p=0.008 n=5+5) [Geo mean] 80.9MB 81.0MB +0.15% name old allocs/op new allocs/op delta Template 348k ± 0% 349k ± 0% +0.38% (p=0.008 n=5+5) Unicode 340k ± 0% 340k ± 0% +0.21% (p=0.008 n=5+5) GoTypes 1.27M ± 0% 1.28M ± 0% +0.27% (p=0.008 n=5+5) Compiler 4.90M ± 0% 4.92M ± 0% +0.36% (p=0.008 n=5+5) SSA 15.3M ± 0% 15.3M ± 0% +0.03% (p=0.008 n=5+5) Flate 232k ± 0% 233k ± 0% +0.14% (p=0.008 n=5+5) GoParser 291k ± 0% 292k ± 0% +0.42% (p=0.008 n=5+5) Reflect 1.05M ± 0% 1.05M ± 0% +0.14% (p=0.008 n=5+5) Tar 343k ± 0% 344k ± 0% +0.22% (p=0.008 n=5+5) XML 428k ± 0% 430k ± 0% +0.36% (p=0.008 n=5+5) [Geo mean] 807k 809k +0.25% Change-Id: I62134db642206cded01920dc1d8a7da61f7ca0ac Reviewed-on: https://go-review.googlesource.com/c/147038 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Michael Anthony Knyszek authored
This change cleans up references to MSpan, MCache, and MCentral in the docs via a bunch of sed invocations to better reflect the Go names for the equivalent structures (i.e. mspan, mcache, mcentral) and their methods (i.e. MSpan_Sweep -> mspan.sweep). Change-Id: Ie911ac975a24bd25200a273086dd835ab78b1711 Reviewed-on: https://go-review.googlesource.com/c/147557Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
TestTracebackAncestors has a ~0.1% chance of failing with more goroutines in the traceback than expected. This happens because there's a window between each goroutine starting its child and that goroutine actually exiting. The test captures its own stack trace after everything is "done", but if this happens during that window, it will include the goroutine that's in the process of being torn down. Here's an example of such a failure: https://build.golang.org/log/fad10d0625295eb79fa879f53b8b32b9d0596af8 This CL fixes this by recording the goroutines that are expected to exit and removing them from the stack trace. With this fix, this test passed 15,000 times with no failures. Change-Id: I71e7c6282987a15e8b74188b9c585aa2ca97cbcd Reviewed-on: https://go-review.googlesource.com/c/147517 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Yury Smolsky authored
This documentation example was broken: https://golang.org/pkg/image/png/#example_Decode. It did not have the "io" package imported, The package was referenced in the result type of the function. The "playExample" function did not inspect the result types of declared functions. This CL adds inspecting of parameters and result types of functions. Fixes #28492 Updates #9679 Change-Id: I6d8b11bad2db8ea8ba69039cfaa914093bdd5132 Reviewed-on: https://go-review.googlesource.com/c/146118 Run-TryBot: Yury Smolsky <yury@smolsky.by> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
Updates #28601 Change-Id: I734fc5ded153126d384f0df912ecd4d208005e49 Reviewed-on: https://go-review.googlesource.com/c/147537 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Robert Griesemer authored
This change re-introduces (temporarily) a work-around for recursive alias type declarations, originally in https://golang.org/cl/35831/ (intended as fix for #18640). The work-around was removed later for a more comprehensive cycle detection check. That check contained a subtle error which made the code appear to work, while in fact creating incorrect types internally. See #25838 for details. By re-introducing the original work-around, we eliminate problems with many simple recursive type declarations involving aliases; specifically cases such as #27232 and #27267. However, the more general problem remains. This CL also fixes the subtle error (incorrect variable use when analyzing a type cycle) mentioned above and now issues a fatal error with a reference to the relevant issue (rather than crashing later during the compilation). While not great, this is better than the current status. The long-term solution will need to address these cycles (see #25838). As a consequence, several old test cases are not accepted anymore by the compiler since they happened to work accidentally only. This CL disables parts or all code of those test cases. The issues are: #18640, #23823, and #24939. One of the new test cases (fixedbugs/issue27232.go) exposed a go/types issue. The test case is excluded from the go/types test suite and an issue was filed (#28576). Updates #18640. Updates #23823. Updates #24939. Updates #25838. Updates #28576. Fixes #27232. Fixes #27267. Change-Id: I6c2d10da98bfc6f4f445c755fcaab17fc7b214c5 Reviewed-on: https://go-review.googlesource.com/c/147286Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I5f7d2155c2c3a47dabdf16fe46b122ede81de4fc Reviewed-on: https://go-review.googlesource.com/c/147284Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Michael Anthony Knyszek authored
As of 07e738ec all spans are allocated out of a treap, and not just large spans or spans for large objects. Also, now we have a separate treap for spans that have been scavenged. Change-Id: I9c2cb7b6798fc536bbd34835da2e888224fd7ed4 Reviewed-on: https://go-review.googlesource.com/c/142958Reviewed-by: Austin Clements <austin@google.com>
-
Austin Clements authored
Change-Id: Ib9dcdc76095f6718f1cdc83349503f52567c76d4 Reviewed-on: https://go-review.googlesource.com/c/60801 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This uses the mutator utilization distribution to compute the p99.9, p99, and p95 mutator utilization topograph lines and display them along with the MMU. Change-Id: I8c7e0ec326aa4bc00619ec7562854253f01cc802 Reviewed-on: https://go-review.googlesource.com/c/60800 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This adds support for computing the quantiles of a mutator utilization distribution. Change-Id: Ia8b3ed14bf415c234e2f567360fd1b361d28bd40 Reviewed-on: https://go-review.googlesource.com/c/60799 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
Change-Id: I672240487172380c9eef61837b41698021aaf834 Reviewed-on: https://go-review.googlesource.com/c/60798 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
The current MMU analysis considers all Ps together, so if, for example, one of four Ps is blocked, mutator utilization is 75%. However, this is less useful for understanding the impact on individual goroutines because that one blocked goroutine could be blocked for a very long time, but we still appear to have good utilization. Hence, this introduces a new flag that does a "per-P" analysis where the utilization of each P is considered independently. The MMU is then the combination of the MMU for each P's utilization function. Change-Id: Id67b980d4d82b511d28300cdf92ccbb5ae8f0c78 Reviewed-on: https://go-review.googlesource.com/c/60797 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
Change-Id: I4ba963b003cb25b39d7575d423f17930d84f3f69 Reviewed-on: https://go-review.googlesource.com/c/60796 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This adds the ability to click a point on the MMU graph to show a list of the worst 10 mutator utilization windows of the selected size. This list in turn links to the trace viewer to drill down on specifically what happened in each specific window. Change-Id: Ic1b72d8b37fbf2212211c513cf36b34788b30133 Reviewed-on: https://go-review.googlesource.com/c/60795 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
This will let the trace viewer show specifically when poor utilization happened and link to specific instances in the trace. Change-Id: I1f03a0f9d9a7570009bb15762e7b8b6f215e9423 Reviewed-on: https://go-review.googlesource.com/c/60793 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This further optimizes MMU construction by first computing a low-resolution summary of the utilization curve. This "band" summary lets us compute the worst-possible window starting in each of these low-resolution bands (even without knowing where in the band the window falls). This in turn lets us compute precise minimum mutator utilization only in the worst low-resolution bands until we can show that any remaining bands can't possibly contain a worse window. This slows down MMU construction for small traces, but these are reasonably fast to compute either way. For large traces (e.g., 150,000+ utilization changes) it's significantly faster. Change-Id: Ie66454e71f3fb06be3f6173b6d91ad75c61bda48 Reviewed-on: https://go-review.googlesource.com/c/60792 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This commit speeds up MMU construction by ~10X (and reduces the number of windows considered by ~20X) by using an observation about the maximum slope of the windowed mutator utilization function to advance the window time in jumps if the window's current mean mutator utilization is much larger than the current minimum. Change-Id: If3cba5da0c4adc37b568740f940793e491e96a51 Reviewed-on: https://go-review.googlesource.com/c/60791 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Austin Clements authored
This adds an endpoint to the trace tool that plots the minimum mutator utilization curve using information on mark assists and GC pauses from the trace. This commit implements a fairly straightforward O(nm) algorithm for computing the MMU (and tests against an even more direct but slower algorithm). Future commits will extend and optimize this algorithm. This should be useful for debugging and understanding mutator utilization issues like #14951, #14812, #18155. #18534, #21107, particularly once follow-up CLs add trace cross-referencing. Change-Id: Ic2866869e7da1e6c56ba3e809abbcb2eb9c4923a Reviewed-on: https://go-review.googlesource.com/c/60790 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Muhammad Falak R Wani authored
Change-Id: I19ff9d231c4cc779b0737802c3c40ee2e00934dd Reviewed-on: https://go-review.googlesource.com/c/147477Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tobias Klauser authored
zgoos_aix.go is missing GoosJs, the order of GoosAndroid and GoosAix is mixed up in all files and GoosHurd was added after CL 146023 introduced GOOS=hurd. Change-Id: I7e2f5a15645272e9020cfca86e44c364fc072a2b Reviewed-on: https://go-review.googlesource.com/c/147397 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 04 Nov, 2018 2 commits
-
-
Elias Naur authored
The kernel on some Samsung S9+ models reports support for arm64 8.1 atomics, but in reality only some of the cores support them. Go programs scheduled to cores without support will crash with SIGILL. This change unconditionally disables the optimization on Android. A better fix is to precisely detect the offending chipset. Fixes #28431 Change-Id: I35a1273e5660603824d30ebef2ce7e429241bf1f Reviewed-on: https://go-review.googlesource.com/c/147377 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
At each comparison, we're making a copy of the whole string. Instead, use unsafe to share the string backing store with a []byte. It reduces the test time from ~4sec to ~1sec on my machine (darwin/amd64). Some builders were having much more trouble with this test (>3min), it may help more there. Fixes #26174 Fixes #28573 Fixes #26155 Update #26473 Change-Id: Id5856fd26faf6ff46e763a088f039230556a4116 Reviewed-on: https://go-review.googlesource.com/c/147358Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 03 Nov, 2018 6 commits
-
-
Robert Griesemer authored
Was only ever filled with one Etype (TFORW) and only used in one place. Easier to just check for TFORW. Change-Id: Icc96da3a22b0af1d7e60bc5841c744916c53341e Reviewed-on: https://go-review.googlesource.com/c/147285Reviewed-by: Martin Möhrmann <moehrmann@google.com>
-
Robert Griesemer authored
The Fatalf mechanism already prints "compiler internal error:" when reporting an error. There's no need to have "internal error" in the error message passed to Fatalf calls. Removed them. Fixes #28575. Change-Id: I12b1bea37bc839780f257c27ef9e2005bf334925 Reviewed-on: https://go-review.googlesource.com/c/147287 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
-
Robert Griesemer authored
Follow-up on https://golang.org/cl/146782. TBR=bradfitz Change-Id: Idaf5488fedfc05d6ff71706fa0bcd70bf98ab25a Reviewed-on: https://go-review.googlesource.com/c/147283Reviewed-by: Robert Griesemer <gri@golang.org>
-
Austin Clements authored
Currently, WriteObjFile deduplicates symbols by name. This is a strange and unexpected place to do this. But, worse, there's no checking that it's reasonable to deduplicate two symbols, so this makes it incredibly easy to mask errors involving duplicate symbols. Dealing with duplicate symbols is better left to the linker. We're also about to introduce multiple symbols with the same name but different ABIs/versions, which would make this deduplication more complicated. We just removed the only part of the compiler that actually depended on this behavior. This CL removes symbol deduplication from WriteObjFile, since it is no longer needed. For #27539. Change-Id: I650c550e46e83f95c67cb6c6646f9b2f7f10df30 Reviewed-on: https://go-review.googlesource.com/c/146558 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Austin Clements authored
Currently, liveness produces a distinct obj.LSym for each GC bitmap for each function. These are then named by content hash and only ultimately deduplicated by WriteObjFile. For various reasons (see next commit), we want to remove this deduplication behavior from WriteObjFile. Furthermore, it's inefficient to produce these duplicate symbols in the first place. GC bitmaps are the only source of duplicate symbols in the compiler. This commit eliminates these duplicate symbols by declaring them in the Ctxt symbol hash just like every other obj.LSym. As a result, all GC bitmaps with the same content now refer to the same obj.LSym. The next commit will remove deduplication from WriteObjFile. For #27539. Change-Id: I4f15e3d99530122cdf473b7a838c69ef5f79db59 Reviewed-on: https://go-review.googlesource.com/c/146557 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Cherry Zhang authored
32-bit negated logical instructions (BICW, ORNW, EONW) with constants were mis-encoded, because they were missing in the cases where we handle 32-bit logical instructions. This CL adds the missing cases. Fixes #28548 Change-Id: I3d6acde7d3b72bb7d3d5d00a9df698a72c806ad5 Reviewed-on: https://go-review.googlesource.com/c/147077 Run-TryBot: Cherry Zhang <cherryyz@google.com> Run-TryBot: Ben Shi <powerman1st@163.com> Reviewed-by: Ben Shi <powerman1st@163.com>
-
- 02 Nov, 2018 10 commits
-
-
Carl Mastrangelo authored
Scanning through all path patterns is not necessary, since the paths do not change frequently. Instead, maintain a sorted list of path prefixes and return the first match. name old time/op new time/op delta ServerMatch-12 134ns ± 3% 17ns ± 4% -86.95% (p=0.000 n=19+20) Change-Id: I15b4483dc30db413321435ee6815fc9bf2bcc546 Reviewed-on: https://go-review.googlesource.com/c/144937Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Go documentation style for boolean funcs is to say: // Foo reports whether ... func Foo() bool (rather than "returns true if") This CL also replaces 4 uses of "iff" with the same "reports whether" wording, which doesn't lose any meaning, and will prevent people from sending typo fixes when they don't realize it's "if and only if". In the past I think we've had the typo CLs updated to just say "reports whether". So do them all at once. (Inspired by the addition of another "returns true if" in CL 146938 in fd_plan9.go) Created with: $ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true iff" | grep -v vendor) $ perl -i -npe 's/returns true if/reports whether/' $(git grep -l "returns true if" | grep -v vendor) Change-Id: Ided502237f5ab0d25cb625dbab12529c361a8b9f Reviewed-on: https://go-review.googlesource.com/c/147037Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
The compiler must first be built with the constant enableTrace set to true (typecheck.go). After that, the -t flag becomes available which enables tracing output of type-checking functions. With enableTrace == false, the tracing code becomes dead code and won't affect the compiler. Typical output might look like this: path/y.go:4:6: typecheck 0xc00033e180 DCLTYPE <node DCLTYPE> tc=0 path/y.go:4:6: . typecheck1 0xc00033e180 DCLTYPE <node DCLTYPE> tc=2 path/y.go:4:6: . . typecheck 0xc000331a40 TYPE T tc=1 path/y.go:4:6: . . . typecheck1 0xc000331a40 TYPE T tc=2 path/y.go:4:6: . . . . typecheckdef 0xc000331a40 TYPE T tc=2 path/y.go:4:6: . . . . => 0xc000331a40 TYPE T tc=2 type=*T path/y.go:4:6: . . . => 0xc000331a40 TYPE T tc=2 type=*T path/y.go:4:6: . . => 0xc000331a40 TYPE T tc=1 type=*T path/y.go:4:6: . => 0xc00033e180 DCLTYPE <node DCLTYPE> tc=2 type=<T> path/y.go:4:6: => 0xc00033e180 DCLTYPE <node DCLTYPE> tc=1 type=<T> Disabled by default. Change-Id: Ifd8385290d1cf0d3fc5e8468b2f4ab84e8eff338 Reviewed-on: https://go-review.googlesource.com/c/146782Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Filippo Valsorda authored
Implement a basic TLS 1.3 server handshake, only enabled if explicitly requested with MaxVersion. This CL intentionally leaves for future CLs: - PSK modes and resumption - client authentication - compatibility mode ChangeCipherSpecs - early data skipping - post-handshake messages - downgrade protection - KeyLogWriter support - TLS_FALLBACK_SCSV processing It also leaves a few areas up for a wider refactor (maybe in Go 1.13): - the certificate selection logic can be significantly improved, including supporting and surfacing signature_algorithms_cert, but this isn't new in TLS 1.3 (see comment in processClientHello) - handshake_server_tls13.go can be dried up and broken into more meaningful, smaller functions, but it felt premature to do before PSK and client auth support - the monstrous ClientHello equality check in doHelloRetryRequest can get both cleaner and more complete with collaboration from the parsing layer, which can come at the same time as extension duplicates detection Updates #9671 Change-Id: Id9db2b6ecc2eea21bf9b59b6d1d9c84a7435151c Reviewed-on: https://go-review.googlesource.com/c/147017 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
Implement a basic TLS 1.3 client handshake, only enabled if explicitly requested with MaxVersion. This CL intentionally leaves for future CLs: - PSK modes and resumption - client authentication - post-handshake messages - downgrade protection - KeyLogWriter support Updates #9671 Change-Id: Ieb6130fb6f25aea4f0d39e3a2448dfc942e1de7a Reviewed-on: https://go-review.googlesource.com/c/146559 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
crypto/x509 already supports PSS signatures (with rsaEncryption OID), and crypto/tls support was added in CL 79736. Advertise support for the algorithms and accept them as a peer. Note that this is about PSS signatures from regular RSA public keys. RSA-PSS only public keys (with RSASSA-PSS OID) are supported in neither crypto/tls nor crypto/x509. See RFC 8446, Section 4.2.3. testdata/Server-TLSv12-ClientAuthRequested* got modified because the CertificateRequest carries the supported signature algorithms. The net/smtp tests changed because 512 bits keys are too small for PSS. Based on Peter Wu's CL 79738, who did all the actual work in CL 79736. Updates #9671 Change-Id: I4a31e9c6e152ff4c50a5c8a274edd610d5fff231 Reviewed-on: https://go-review.googlesource.com/c/146258 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
RFC 8446 recommends using the supported_versions extension to negotiate lower versions as well, so begin by implementing it to negotiate the currently supported versions. Note that pickTLSVersion was incorrectly negotiating the ServerHello version down on the client. If the server had illegally sent a version higher than the ClientHello version, the client would have just downgraded it, hopefully failing later in the handshake. In TestGetConfigForClient, we were hitting the record version check because the server would select TLS 1.1, the handshake would fail on the client which required TLS 1.2, which would then send a TLS 1.0 record header on its fatal alert (not having negotiated a version), while the server would expect a TLS 1.1 header at that point. Now, the client gets to communicate the minimum version through the extension and the handshake fails on the server. Updates #9671 Change-Id: Ie33c7124c0c769f62e10baad51cbed745c424e5b Reviewed-on: https://go-review.googlesource.com/c/146217 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
Note that there is significant code duplication due to extensions with the same format appearing in different messages in TLS 1.3. This will be cleaned up in a future refactor once CL 145317 is merged. Enforcing the presence/absence of each extension in each message is left to the upper layer, based on both protocol version and extensions advertised in CH and CR. Duplicated extensions and unknown extensions in SH, EE, HRR, and CT will be tightened up in a future CL. The TLS 1.2 CertificateStatus message was restricted to accepting only type OCSP as any other type (none of which are specified so far) would have to be negotiated. Updates #9671 Change-Id: I7c42394c5cc0af01faa84b9b9f25fdc6e7cfbb9e Reviewed-on: https://go-review.googlesource.com/c/145477Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
Vendors golang.org/x/crypto/hkdf at e84da0312774c21d64ee2317962ef669b27ffb41 Updates #9671 Change-Id: I2610c4a66756e2a6f21f9823dcbe39edd9c9ea21 Reviewed-on: https://go-review.googlesource.com/c/145298Reviewed-by: Adam Langley <agl@golang.org>
-
Filippo Valsorda authored
Updates #9671 Change-Id: I1ea7b724975c0841d01f4536eebb23956b30d5ea Reviewed-on: https://go-review.googlesource.com/c/145297Reviewed-by: Adam Langley <agl@golang.org>
-