- 28 Oct, 2016 33 commits
-
-
Russ Cox authored
Let users control whether unix listener socket file is unlinked on close. Fixes #13877. Change-Id: I9d1cb47e31418d655f164d15c67e188656a67d1c Reviewed-on: https://go-review.googlesource.com/32099 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #17131. Change-Id: I60b381687746fadce12ef18a190cbe3f435172f2 Reviewed-on: https://go-review.googlesource.com/32098 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Quentin Smith <quentin@golang.org>
-
Austin Clements authored
Since barrier-less memclr is only safe in very narrow circumstances, this commit renames memclr to avoid accidentally calling memclr on typed memory. This can cause subtle, non-deterministic bugs, so it's worth some effort to prevent. In the near term, this will also prevent bugs creeping in from any concurrent CLs that add calls to memclr; if this happens, whichever patch hits master second will fail to compile. This also adds the other new memclr variants to the compiler's builtin.go to minimize the churn on that binary blob. We'll use these in future commits. Updates #17503. Change-Id: I00eead049f5bd35ca107ea525966831f3d1ed9ca Reviewed-on: https://go-review.googlesource.com/31369Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently fixalloc does not zero memory it reuses. This is dangerous with the hybrid barrier if the type may contain heap pointers, since it may cause us to observe a dead heap pointer on reuse. It's also error-prone since it's the only allocator that doesn't zero on allocation (mallocgc of course zeroes, but so do persistentalloc and sysAlloc). It's also largely pointless: for mcache, the caller immediately memclrs the allocation; and the two specials types are tiny so there's no real cost to zeroing them. Change fixalloc to zero allocations by default. The only type we don't zero by default is mspan. This actually requires that the spsn's sweepgen survive across freeing and reallocating a span. If we were to zero it, the following race would be possible: 1. The current sweepgen is 2. Span s is on the unswept list. 2. Direct sweeping sweeps span s, finds it's all free, and releases s to the fixalloc. 3. Thread 1 allocates s from fixalloc. Suppose this zeros s, including s.sweepgen. 4. Thread 1 calls s.init, which sets s.state to _MSpanDead. 5. On thread 2, background sweeping comes across span s in allspans and cas's s.sweepgen from 0 (sg-2) to 1 (sg-1). Now it thinks it owns it for sweeping. 6. Thread 1 continues initializing s. Everything breaks. I would like to fix this because it's obviously confusing, but it's a subtle enough problem that I'm leaving it alone for now. The solution may be to skip sweepgen 0, but then we have to think about wrap-around much more carefully. Updates #17503. Change-Id: Ie08691feed3abbb06a31381b94beb0a2e36a0613 Reviewed-on: https://go-review.googlesource.com/31368Reviewed-by:
-
Austin Clements authored
Currently the zero value of an mspan is in the "in use" state. This seems like a bad idea in general. But it's going to wreak havoc when we make fixalloc zero allocations: even "freed" mspan objects are still on the allspans list and still get looked at by the garbage collector. Hence, if we leave the mspan states the way they are, allocating a span that reuses old memory will temporarily pass that span (which is visible to GC!) through the "in use" state, which can cause "unswept span" panics. Fix all of this by making the zero state "dead". Updates #17503. Change-Id: I77c7ac06e297af4b9e6258bc091c37abe102acc3 Reviewed-on: https://go-review.googlesource.com/31367Reviewed-by:
-
Austin Clements authored
The hybrid barrier requires distinguishing typed and untyped memory even when zeroing because the *current* contents of the memory matters even when overwriting. This commit introduces runtime.typedmemclr and runtime.memclrHasPointers as a typed memory clearing functions parallel to runtime.typedmemmove. Currently these simply call memclr, but with the hybrid barrier we'll need to shade any pointers we're overwriting. These will provide us with the necessary hooks to do so. Updates #17503. Change-Id: I74478619f8907825898092aaa204d6e4690f27e6 Reviewed-on: https://go-review.googlesource.com/31366Reviewed-by:
-
Austin Clements authored
Currently all mcaches are flushed in a single STW root job. This takes about 5 µs per P, but since it's done sequentially it adds about 5*GOMAXPROCS µs to the STW. Fix this by parallelizing the job. Since there are exactly GOMAXPROCS mcaches to flush, this parallelizes quite nicely and brings the STW latency cost down to a constant 5 µs (assuming GOMAXPROCS actually reflects the number of CPUs). Updates #17503. Change-Id: Ibefeb1c2229975d5137c6e67fac3b6c92103742d Reviewed-on: https://go-review.googlesource.com/32033Reviewed-by:
-
Josh Bleecher Snyder authored
ONONAME nodes generated from unresolved symbols don't need Params. They only need Names to store Iota; move Iota to Node.Xoffset. While we're here, change iota to int64 to reduce casting. Passes toolstash -cmp. name old alloc/op new alloc/op delta Template 39.9MB ± 0% 39.7MB ± 0% -0.39% (p=0.000 n=19+20) Unicode 30.9MB ± 0% 30.7MB ± 0% -0.35% (p=0.000 n=20+20) GoTypes 119MB ± 0% 118MB ± 0% -0.42% (p=0.000 n=20+20) Compiler 464MB ± 0% 461MB ± 0% -0.54% (p=0.000 n=19+20) name old allocs/op new allocs/op delta Template 386k ± 0% 383k ± 0% -0.62% (p=0.000 n=20+20) Unicode 323k ± 0% 321k ± 0% -0.49% (p=0.000 n=20+20) GoTypes 1.16M ± 0% 1.15M ± 0% -0.67% (p=0.000 n=20+20) Compiler 4.09M ± 0% 4.05M ± 0% -0.95% (p=0.000 n=20+20) Change-Id: Ib27219a0d0405def1b4dadacf64935ba12d10a94 Reviewed-on: https://go-review.googlesource.com/32237 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
unknown authored
Added functions with suffix proto and stuff from pprof tool to translate to protobuf. Done as the profile proto is more extensible than the legacy pprof format and is pprof's preferred profile format. Large part was taken from https://github.com/google/pprof tool. Tested by hand and compared the result with translated by pprof tool, profiles are identical. Fixes #16093 Change-Id: I5acdb2809cab0d16ed4694fdaa7b8ddfd68df11e Reviewed-on: https://go-review.googlesource.com/30556 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Michael Matloob <matloob@golang.org>
-
Austin Clements authored
The current logic in gcDrain conflates non-blocking with preemptible draining for root jobs. As a result, if you do a non-blocking (but *not* preemptible) drain, like dedicated workers do, the root job drain will stop if preempted and fall through to heap marking jobs, which won't stop until it fails to get a heap marking job. This commit fixes the condition on root marking jobs so they only stop when preempted if the drain is preemptible. Coincidentally, this also fixes a nil pointer dereference if we call gcDrain with gcDrainNoBlock and without a user G, since it tries to get the preempt flag from the nil user G. This combination never happens right now, but will in the future. Change-Id: Ia910ec20a9b46237f7926969144a33b1b4a7b2f9 Reviewed-on: https://go-review.googlesource.com/32291 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
This adds support to the runtime/trace test for saving traces collected by its tests to disk and a script in internal/trace that uses this to collect canned traces for the trace test suite. This can be used to add to the test suite when we introduce a new trace format version. Change-Id: Id9ac1ff312235bf02f982fdfff8a827f54035758 Reviewed-on: https://go-review.googlesource.com/32290 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Joe Tsai authored
In a large codebase within Google, there are thousands of uses of: ContainsAny|IndexAny|LastIndexAny|Trim|TrimLeft|TrimRight An analysis of their usage shows that over 97% of them only use character sets consisting of only ASCII symbols. Uses of ContainsAny|IndexAny|LastIndexAny: 6% are 1 character (e.g., "\n" or " ") 58% are 2-4 characters (e.g., "<>" or "\r\n\t ") 24% are 5-9 characters (e.g., "()[]*^$") 10% are 10+ characters (e.g., "+-=&|><!(){}[]^\"~*?:\\/ ") We optimize for ASCII sets, which are commonly used to search for "control" characters in some string. We don't optimize for the single character scenario since IndexRune or IndexByte could be used. Uses of Trim|TrimLeft|TrimRight: 71% are 1 character (e.g., "\n" or " ") 14% are 2 characters (e.g., "\r\n") 10% are 3-4 characters (e.g., " \t\r\n") 5% are 10+ characters (e.g., "0123456789abcdefABCDEF") We optimize for the single character case with a simple closured function that only checks for that character's value. We optimize for the medium and larger sets using a 16-byte bit-map representing a set of ASCII characters. The benchmarks below have the following suffix name "%d:%d" where the first number is the length of the input and the second number is the length of the charset. == bytes package == benchmark old ns/op new ns/op delta BenchmarkIndexAnyASCII/1:1-4 5.09 5.23 +2.75% BenchmarkIndexAnyASCII/1:2-4 5.81 5.85 +0.69% BenchmarkIndexAnyASCII/1:4-4 7.22 7.50 +3.88% BenchmarkIndexAnyASCII/1:8-4 11.0 11.1 +0.91% BenchmarkIndexAnyASCII/1:16-4 17.5 17.8 +1.71% BenchmarkIndexAnyASCII/16:1-4 36.0 34.0 -5.56% BenchmarkIndexAnyASCII/16:2-4 46.6 36.5 -21.67% BenchmarkIndexAnyASCII/16:4-4 78.0 40.4 -48.21% BenchmarkIndexAnyASCII/16:8-4 136 47.4 -65.15% BenchmarkIndexAnyASCII/16:16-4 254 61.5 -75.79% BenchmarkIndexAnyASCII/256:1-4 542 388 -28.41% BenchmarkIndexAnyASCII/256:2-4 705 382 -45.82% BenchmarkIndexAnyASCII/256:4-4 1089 386 -64.55% BenchmarkIndexAnyASCII/256:8-4 1994 394 -80.24% BenchmarkIndexAnyASCII/256:16-4 3843 411 -89.31% BenchmarkIndexAnyASCII/4096:1-4 8522 5873 -31.08% BenchmarkIndexAnyASCII/4096:2-4 11253 5861 -47.92% BenchmarkIndexAnyASCII/4096:4-4 17824 5883 -66.99% BenchmarkIndexAnyASCII/4096:8-4 32053 5871 -81.68% BenchmarkIndexAnyASCII/4096:16-4 60512 5888 -90.27% BenchmarkTrimASCII/1:1-4 79.5 70.8 -10.94% BenchmarkTrimASCII/1:2-4 79.0 105 +32.91% BenchmarkTrimASCII/1:4-4 79.6 109 +36.93% BenchmarkTrimASCII/1:8-4 78.8 118 +49.75% BenchmarkTrimASCII/1:16-4 80.2 132 +64.59% BenchmarkTrimASCII/16:1-4 243 116 -52.26% BenchmarkTrimASCII/16:2-4 243 171 -29.63% BenchmarkTrimASCII/16:4-4 243 176 -27.57% BenchmarkTrimASCII/16:8-4 241 184 -23.65% BenchmarkTrimASCII/16:16-4 238 199 -16.39% BenchmarkTrimASCII/256:1-4 2580 840 -67.44% BenchmarkTrimASCII/256:2-4 2603 1175 -54.86% BenchmarkTrimASCII/256:4-4 2572 1188 -53.81% BenchmarkTrimASCII/256:8-4 2550 1191 -53.29% BenchmarkTrimASCII/256:16-4 2585 1208 -53.27% BenchmarkTrimASCII/4096:1-4 39773 12181 -69.37% BenchmarkTrimASCII/4096:2-4 39946 17231 -56.86% BenchmarkTrimASCII/4096:4-4 39641 17179 -56.66% BenchmarkTrimASCII/4096:8-4 39835 17175 -56.88% BenchmarkTrimASCII/4096:16-4 40229 17215 -57.21% == strings package == benchmark old ns/op new ns/op delta BenchmarkIndexAnyASCII/1:1-4 5.94 4.97 -16.33% BenchmarkIndexAnyASCII/1:2-4 5.94 5.55 -6.57% BenchmarkIndexAnyASCII/1:4-4 7.45 7.21 -3.22% BenchmarkIndexAnyASCII/1:8-4 10.8 10.6 -1.85% BenchmarkIndexAnyASCII/1:16-4 17.4 17.2 -1.15% BenchmarkIndexAnyASCII/16:1-4 36.4 32.2 -11.54% BenchmarkIndexAnyASCII/16:2-4 49.6 34.6 -30.24% BenchmarkIndexAnyASCII/16:4-4 77.5 37.9 -51.10% BenchmarkIndexAnyASCII/16:8-4 138 45.5 -67.03% BenchmarkIndexAnyASCII/16:16-4 241 59.1 -75.48% BenchmarkIndexAnyASCII/256:1-4 509 378 -25.74% BenchmarkIndexAnyASCII/256:2-4 720 381 -47.08% BenchmarkIndexAnyASCII/256:4-4 1142 384 -66.37% BenchmarkIndexAnyASCII/256:8-4 1999 391 -80.44% BenchmarkIndexAnyASCII/256:16-4 3735 403 -89.21% BenchmarkIndexAnyASCII/4096:1-4 7973 5824 -26.95% BenchmarkIndexAnyASCII/4096:2-4 11432 5809 -49.19% BenchmarkIndexAnyASCII/4096:4-4 18327 5819 -68.25% BenchmarkIndexAnyASCII/4096:8-4 33059 5828 -82.37% BenchmarkIndexAnyASCII/4096:16-4 59703 5817 -90.26% BenchmarkTrimASCII/1:1-4 71.9 71.8 -0.14% BenchmarkTrimASCII/1:2-4 73.3 103 +40.52% BenchmarkTrimASCII/1:4-4 71.8 106 +47.63% BenchmarkTrimASCII/1:8-4 71.2 113 +58.71% BenchmarkTrimASCII/1:16-4 71.6 128 +78.77% BenchmarkTrimASCII/16:1-4 152 116 -23.68% BenchmarkTrimASCII/16:2-4 160 168 +5.00% BenchmarkTrimASCII/16:4-4 172 170 -1.16% BenchmarkTrimASCII/16:8-4 200 177 -11.50% BenchmarkTrimASCII/16:16-4 254 193 -24.02% BenchmarkTrimASCII/256:1-4 1438 864 -39.92% BenchmarkTrimASCII/256:2-4 1551 1195 -22.95% BenchmarkTrimASCII/256:4-4 1770 1200 -32.20% BenchmarkTrimASCII/256:8-4 2195 1216 -44.60% BenchmarkTrimASCII/256:16-4 3054 1224 -59.92% BenchmarkTrimASCII/4096:1-4 21726 12557 -42.20% BenchmarkTrimASCII/4096:2-4 23586 17508 -25.77% BenchmarkTrimASCII/4096:4-4 26898 17510 -34.90% BenchmarkTrimASCII/4096:8-4 33714 17595 -47.81% BenchmarkTrimASCII/4096:16-4 47429 17700 -62.68% The benchmarks added test the worst case. For IndexAny, that is when the charset matches none of the input. For Trim, it is when the charset matches all of the input. Change-Id: I970874d101a96b33528fc99b165379abe58cf6ea Reviewed-on: https://go-review.googlesource.com/31593 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Martin Möhrmann <martisch@uos.de>
-
Russ Cox authored
The report in #17414 points out that if you have many many templates, then this is an overwhelming list and just hurts the signal-to-noise ratio of the error. Even the test of the old behavior also supports the idea that this is noise: template: empty: "empty" is an incomplete or empty template; defined templates are: "secondary" The chance that someone mistyped "secondary" as "empty" is slim at best. Similarly, the compiler does not augment an error like 'unknown variable x' by dumping the full list of all the known variables. For all these reasons, drop the list. Fixes #17414. Change-Id: I78f92d2c591df7218385fe723a4abc497913acf8 Reviewed-on: https://go-review.googlesource.com/32116 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
Fixes #16731. Change-Id: I6d393357973d008ab7cf5fb264acb7d38c9354eb Reviewed-on: https://go-review.googlesource.com/32104 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Follow-up on https://go-review.googlesource.com/30601. Change-Id: I51b603a6c4877b571e83cd7c4e78a8988cc831ca Reviewed-on: https://go-review.googlesource.com/32310Reviewed-by:
-
Josh Chorlton authored
Following RFC 6265 Section 5.1.1.5, ensure that the minimum year for which an Expires value is valid and can be included in the cookie's string, is 1601 instead of the Epoch year 1970. A detailed specification for parsing the Expiry field is at: https://tools.ietf.org/html/rfc6265#section-5.2.1 I stumbled across this bug due to this StackOverflow answer that recommends setting the Expiry to the Epoch: http://stackoverflow.com/a/5285982 Fixes #17632 Change-Id: I3c1bdf821d369320334a5dc1e4bf22783cbfe9fc Reviewed-on: https://go-review.googlesource.com/32142Reviewed-by:
-
Russ Cox authored
This lets quotedprintable handle some inputs found in the wild, most notably generated by "Microsoft CDO for Exchange 2000", and it also matches how Python's quopri package handles these inputs. Fixes #13219. Change-Id: I69d400659d01b6ea0f707b7053d61803a85b4799 Reviewed-on: https://go-review.googlesource.com/32174Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Jaana Burcu Dogan authored
Fixes #17152. Change-Id: I4dd5e505c65f3efe736e46d3781cccf31d7f574f Reviewed-on: https://go-review.googlesource.com/32117Reviewed-by:
-
Brad Fitzpatrick authored
We thought it would at the time, but then Beta 4 changed the ABI again, so it wasn't true in practice. Fixes #17643 Change-Id: I36b747bd69a56adc7291fa30d6bffdf67ab8741b Reviewed-on: https://go-review.googlesource.com/32238Reviewed-by:
-
Austin Clements authored
Currently when a goroutine blocks on a GC assist, it emits a generic EvGoBlock event. Since assist blocking events and, in particular, the length of the blocked assist queue, are important for diagnosing GC behavior, this commit adds a new EvGoBlockGC event for blocking on a GC assist. The trace viewer uses this event to report a "waiting on GC" count in the "Goroutines" row. This makes sense because, unlike other blocked goroutines, these goroutines do have work to do, so being blocked on a GC assist is quite similar to being in the "runnable" state, which we also report in the trace viewer. Change-Id: Ic21a326992606b121ea3d3d00110d8d1fdc7a5ef Reviewed-on: https://go-review.googlesource.com/30704 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently the trace tool tracks an overall counts of goroutine states, but not the states of any individual goroutine. We're about to add more sophisticated blocked-state tracking, so add this tracking and base the state counts off the tracked goroutine states. Change-Id: I943ed61782436cf9540f4ee26c5561715c5b4a1d Reviewed-on: https://go-review.googlesource.com/30703 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently mark workers are shown in the trace as regular goroutines labeled "runtime.gcBgMarkWorker". That's somewhat unhelpful to an end user because of the opaque label and particularly unhelpful to runtime developers because it doesn't distinguish the different types of mark workers. Fix this by introducing a variant of the GoStart event called GoStartLabel that lets the runtime indicate a label for a goroutine execution span and using this to label mark worker executions as "GC (<mode>)" in the trace viewer. Since this bumps the trace version to 1.8, we also add test data for 1.7 traces. Change-Id: Id7b9c0536508430c661ffb9e40e436f3901ca121 Reviewed-on: https://go-review.googlesource.com/30702 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cherry Zhang authored
The mechanism is initially introduced (and reviewed) in CL 30597 on S390X. Reduce number of "spilled value remains" by 0.4% in cmd/go. Disabled on ARMv5 because LR is clobbered almost everywhere with inserted softfloat calls. Change-Id: I2934737ce2455909647ed2118fe2bd6f0aa5ac52 Reviewed-on: https://go-review.googlesource.com/32178 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Cherry Zhang authored
Materialize float constant 0 from integer zero register, instead of loading from constant pool. Change-Id: Ie4728895b9d617bec2a29d15729c0efaa10eedbb Reviewed-on: https://go-review.googlesource.com/32109 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Carlos Eduardo Seo authored
The current implementation for Power architecture does not include the vector scalar (VSX) registers. This adds the 63 VSX registers and the most commonly used instructions: load/store VSX vector/scalar, move to/from VSR, logical operations, select, merge, splat, permute, shift, FP-FP conversion, FP-integer conversion and integer-FP conversion. Change-Id: I0f7572d2359fe7f3ea0124a1eb1b0bebab33649e Reviewed-on: https://go-review.googlesource.com/30510Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by:
-
David Crawshaw authored
Based on the calling convention documented in: https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx and long-used in golang.org/x/mobile/gl via some fixup asm: https://go.googlesource.com/mobile/+/master/gl/work_windows_amd64.s Fixes #6510 Change-Id: I97e81baaa2872bcd732b1308915eb66f1ba2168f Reviewed-on: https://go-review.googlesource.com/32173 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Reviewed-by:
Minux Ma <minux@golang.org>
-
Austin Clements authored
Currently, gcDrain looks for the preemption flag at getg().preempt. However, commit d6625caf moved mark worker draining to the system stack, which means getg() returns the g0, which never has the preempt flag set, so idle and fractional workers don't get preempted after 10ms and just run until they run out of work. As a result, if there's enough idle time, GC becomes effectively STW. Fix this by looking for the preemption flag on getg().m.curg, which will always be the user G (where the preempt flag is set), regardless of whether gcDrain is running on the user or the g0 stack. Change-Id: Ib554cf49a705b86ccc3d08940bc869f868c50dd2 Reviewed-on: https://go-review.googlesource.com/32251 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Peter Weinberger authored
runtime.SetMutexProfileFraction(n int) will capture 1/n-th of stack traces of goroutines holding contended mutexes if n > 0. From runtime/pprof, pprot.Lookup("mutex").WriteTo writes the accumulated stack traces to w (in essentially the same format that blocking profiling uses). Change-Id: Ie0b54fa4226853d99aa42c14cb529ae586a8335a Reviewed-on: https://go-review.googlesource.com/29650Reviewed-by:Austin Clements <austin@google.com>
-
Martin Möhrmann authored
- removes the runtime function stringtoslicebytetmp - removes the generation of calls to stringtoslicebytetmp from the frontend - adds handling of OSTRARRAYBYTETMP in the backend This reduces binary sizes and avoids function call overhead. Change-Id: Ib9988d48549cee663b685b4897a483f94727b940 Reviewed-on: https://go-review.googlesource.com/32158Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
I do not know why it is included. All tests pass without it. Change-Id: I839076ee131816dfd177570a902c69fe8fba5022 Reviewed-on: https://go-review.googlesource.com/32144 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
name old allocs/op new allocs/op delta Template 389k ± 0% 386k ± 0% -0.84% (p=0.000 n=10+10) Unicode 323k ± 0% 323k ± 0% -0.25% (p=0.000 n=10+10) GoTypes 1.17M ± 0% 1.16M ± 0% -0.93% (p=0.000 n=10+10) Compiler 4.13M ± 0% 4.09M ± 0% -1.05% (p=0.000 n=10+10) Change-Id: I6c00850d07511c2e65761c7373fc3df738499105 Reviewed-on: https://go-review.googlesource.com/32235 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
David Crawshaw <crawshaw@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
name old allocs/op new allocs/op delta Template 394k ± 0% 391k ± 0% -0.80% (p=0.000 n=10+10) Unicode 350k ± 0% 349k ± 0% -0.27% (p=0.000 n=10+10) GoTypes 1.18M ± 0% 1.17M ± 0% -0.92% (p=0.000 n=10+10) Compiler 4.18M ± 0% 4.14M ± 0% -1.05% (p=0.000 n=10+10) Change-Id: I838a4e2110afe6496c535b9a0ec5aa882d63a707 Reviewed-on: https://go-review.googlesource.com/32223 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nigel Tao authored
Change-Id: Ib9309ee499fc51be2662d778430ee30089822e57 Reviewed-on: https://go-review.googlesource.com/32143Reviewed-by:
-
- 27 Oct, 2016 7 commits
-
-
Matthew Dempsky authored
Keys are uncommon in array and slice literals, and normalizing OARRAYLIT and OSLICELIT nodes to always use OKEY ends up not reducing complexity much. Instead, only create OKEY nodes to represent explicit keys, and recalculate implicit keys when/where necessary. Fixes #15350. name old time/op new time/op delta Template 299ms ± 9% 299ms ±12% ~ (p=0.694 n=28+30) Unicode 165ms ± 7% 162ms ± 9% ~ (p=0.084 n=27+27) GoTypes 950ms ± 9% 963ms ± 5% ~ (p=0.301 n=30+29) Compiler 4.23s ± 7% 4.17s ± 7% ~ (p=0.057 n=29+27) name old user-ns/op new user-ns/op delta Template 389M ±15% 400M ±12% ~ (p=0.202 n=30+29) Unicode 246M ±21% 232M ±22% -5.76% (p=0.006 n=28+29) GoTypes 1.34G ± 8% 1.34G ± 7% ~ (p=0.775 n=28+30) Compiler 5.91G ± 6% 5.87G ± 7% ~ (p=0.298 n=28+29) name old alloc/op new alloc/op delta Template 41.2MB ± 0% 41.2MB ± 0% ~ (p=0.085 n=30+30) Unicode 34.0MB ± 0% 31.5MB ± 0% -7.28% (p=0.000 n=30+29) GoTypes 121MB ± 0% 121MB ± 0% ~ (p=0.657 n=30+30) Compiler 511MB ± 0% 511MB ± 0% -0.01% (p=0.001 n=29+29) name old allocs/op new allocs/op delta Template 390k ± 0% 390k ± 0% ~ (p=0.225 n=30+29) Unicode 318k ± 0% 293k ± 0% -8.03% (p=0.000 n=30+29) GoTypes 1.16M ± 0% 1.16M ± 0% ~ (p=0.745 n=30+30) Compiler 4.35M ± 0% 4.35M ± 0% ~ (p=0.105 n=30+30) Change-Id: I6310739a0bfdb54f1ab8a460b2c03615ad1ff5bc Reviewed-on: https://go-review.googlesource.com/32221Reviewed-by:
-
Nigel Tao authored
Change-Id: I99b9a51db29d514ebaa9c1cfde65c0b5184c0f42 Reviewed-on: https://go-review.googlesource.com/32140Reviewed-by:
-
Cherry Zhang authored
It looks like a typo in CL 30707. Change-Id: Ia2d013567dbd1a49901d9be0cd2d5a103e6e38cf Reviewed-on: https://go-review.googlesource.com/32187 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
For cases where we already have the ops, combine sign or zero extension with the previous load (even if the load is larger width). Update #15105 Change-Id: I76c5ddd69e1f900d2a17d35503083bd3b4978e48 Reviewed-on: https://go-review.googlesource.com/28190 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Use a local map during inlining instead. Change-Id: I10cd19885e7124f812bb04a79dbda52bfebfe1a1 Reviewed-on: https://go-review.googlesource.com/32225 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
var x uint64 uint8(x >> 56) We don't need to generate any code for the uint8(). Update #15090 Change-Id: Ie1ca4e32022dccf7f7bc42d531a285521fb67872 Reviewed-on: https://go-review.googlesource.com/28191 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
When we do var x []byte = ... y := x[i:] We can't just use y.ptr = x.ptr + i, as the new pointer may point to the next object in memory after the backing array. We used to fix this by doing: y.cap = x.cap - i delta := i if y.cap == 0 { delta = 0 } y.ptr = x.ptr + delta That generates a branch in what is otherwise straight-line code. Better to do: y.cap = x.cap - i mask := (y.cap - 1) >> 63 // -1 if y.cap==0, 0 otherwise y.ptr = x.ptr + i &^ mask It's about the same number of instructions (~4, depending on what parts are constant, and the target architecture), but it is all inline. It plays nicely with CSE, and the mask can be computed in parallel with the index (in cases where a multiply is required). It is a minor win in both speed and space. Change-Id: Ied60465a0b8abb683c02208402e5bb7ac0e8370f Reviewed-on: https://go-review.googlesource.com/32022 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Cherry Zhang <cherryyz@google.com>
-
