- 22 Apr, 2016 19 commits
-
-
Matthew Dempsky authored
Instead of switching on Ctype (which internally uses a type switch) and then scattering lots of type assertions throughout the CTFOO case clauses, just use type switches directly on the underlying constant value. Passes toolstash/buildall. Change-Id: I9bc172cc67e5f391cddc15539907883b4010689e Reviewed-on: https://go-review.googlesource.com/22384 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dmitry Vyukov authored
Change-Id: I037101b1921fe151695d32e9874b50dd64982298 Reviewed-on: https://go-review.googlesource.com/22314Reviewed-by: Austin Clements <austin@google.com>
-
Matthew Dempsky authored
Change-Id: Idab5f603c1743895b8f4edbcc55f7be83419a099 Reviewed-on: https://go-review.googlesource.com/22383 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Ian Lance Taylor authored
CL 22372 changed ppc64le to use normal cgo initialization on ppc64le. Doing this uncovered a cmd/link error using internal linking. Opened issue 15409 for the problem. This CL disables the test. Update #15409. Change-Id: Ia1bb6b874c1b5a4df1a0436c8841c145142c30f7 Reviewed-on: https://go-review.googlesource.com/22379 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitry Vyukov authored
Generate new protobuf pprof profiles with embed symbol info. This makes program binary unnecessary. Change-Id: Ie628439c13c5e34199782031138102c83ea50621 Reviewed-on: https://go-review.googlesource.com/21873Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
-
David Chase authored
Replaced incorrect recursion-free rendering of DFS with something that was correct. Enhanced test with all permutations of IF successors to ensure that all possible DFS traversals are exercised. Test is improved version of https://go-review.googlesource.com/#/c/22334 Update 15084. Change-Id: I6e944c41244e47fe5f568dfc2b360ff93b94079e Reviewed-on: https://go-review.googlesource.com/22347Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: David Chase <drchase@google.com>
-
Michael Munday authored
This reverses the change to this benchmark made in 9b6bf20a. Change-Id: I79ab88286c3028d3be561957140375bbc413e7ab Reviewed-on: https://go-review.googlesource.com/22340 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
-
Chris Zou authored
The input buffer is aligned to a doubleword boundary to improve performance of the vector instructions. The pure Go implementation is used to align the input data, and is also used when the vector instructions are not available or the data length is less than 64 bytes. Change-Id: Ie259a5f2f1562bcc17961c99e5776c99091d6bed Reviewed-on: https://go-review.googlesource.com/22201Reviewed-by: Michael Munday <munday@ca.ibm.com> Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alexandru Moșoi authored
Remove the "optimization" that was causing the issue. For the following code the "optimization" was converting v to (OpCopy x) which is wrong because x doesn't dominate v. b1: y = ... First .. b3 b2: x = ... Goto b3 b3: v = phi x y ... use v ... That "optimization" is likely no longer needed because we now have a second opt pass with a dce in between which removes blocks of type First. For pkg/tools/linux_amd64/* the binary size drops from 82142886 to 82060034. Change-Id: I10428abbd8b32c5ca66fec3da2e6f3686dddbe31 Reviewed-on: https://go-review.googlesource.com/22312 Run-TryBot: Alexandru Moșoi <alexandru@mosoi.ro> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Alexandru Moșoi authored
See discussion at [1]. True value must have a fixed non-zero representation meaning that a && b can be implemented as a & b. [1] https://groups.google.com/forum/#!topic/golang-dev/xV0vPuFP9Vg This change helps with m := a && b, but it's more common to see if a && b { do something } which is not handled. Change-Id: Ib6f9ff898a0a8c05d12466e2464e4fe781035394 Reviewed-on: https://go-review.googlesource.com/22313 Run-TryBot: Alexandru Moșoi <alexandru@mosoi.ro> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
They are guaranteed to be non-nil, no point in inserting nil checks for them. Fixes #15390 Change-Id: I3b9a0f2319affc2139dcc446d0a56c6785ae5a86 Reviewed-on: https://go-review.googlesource.com/22291Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Ian Lance Taylor authored
The special case was because PPC did not support external linking, but now it does. Fixes #10410. Change-Id: I9b024686e0f03da7a44c1c59b41c529802f16ab0 Reviewed-on: https://go-review.googlesource.com/22372 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
linux/amd64 PIE: cmd/go: -62KB (0.5%) jujud: -550KB (0.7%) For #6853. Change-Id: Ieb67982abce5832e24b997506f0ae7108f747108 Reviewed-on: https://go-review.googlesource.com/22371 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
linux/amd64: cmd/go: -8KB (basically nothing) linux/amd64 PIE: cmd/go: -191KB (1.6%) jujud: -1.5MB (1.9%) Updates #6853 Fixes #15064 Change-Id: I0adbb95685e28be92e8548741df0e11daa0a9b5f Reviewed-on: https://go-review.googlesource.com/21777Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Crawshaw authored
Now that reflect.name objects contain an offset to pkgPath instead of a pointer, there is no need to align the symbol data. Removes approx. 10KB from the cmd/go binary. The effect becomes more important later as more type data is moved into name objects. For #6853 Change-Id: Idb507fdbdad04f16fc224378f82272cb5c236ab7 Reviewed-on: https://go-review.googlesource.com/21776 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Munday authored
Use the compute intermediate message digest (KIMD) instruction when possible. Adds test to check fallback code path in case KIMD is not available. Benchmark changes: Hash8Bytes 3.4x Hash1K 9.3x Hash8K 10.9x Change-Id: Ibcd71a886dfd7b3822042235b4f4eaa7a148036b Reviewed-on: https://go-review.googlesource.com/22350 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Gerrand authored
Document the subtle property that files with equivalent base names will overwrite extant templates with those same names. Fixes golang/go#14320 Change-Id: Ie9ace1b08e6896ea599836e31582123169aa7a25 Reviewed-on: https://go-review.googlesource.com/21824Reviewed-by: Rob Pike <r@golang.org>
-
Andrew Gerrand authored
Before this change, a go-vendor-issue-14613 file would be left in the working directory after tests run. Change-Id: If1858421bb287215ab4a19163f489131b2e8912c Reviewed-on: https://go-review.googlesource.com/22169Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Rob Pike authored
Fixes #13808. Change-Id: Ifbd5644da995a812438a405485c9e08b4503a313 Reviewed-on: https://go-review.googlesource.com/22352Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 21 Apr, 2016 21 commits
-
-
Robert Griesemer authored
Change-Id: I2275dc703be4fda3feedf76483148eab853b43b8 Reviewed-on: https://go-review.googlesource.com/22360 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I6490de325b0f4ba962c679503102d30d41dcc384 Reviewed-on: https://go-review.googlesource.com/22359 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Hudson-Doyle authored
Does anyone actually pass -a to the linker? Change-Id: I1d31ea66aa5604b7fd42adf15bdab71e9f52d0ed Reviewed-on: https://go-review.googlesource.com/22356 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Rob Pike authored
Change-Id: I4fc35649ff5a3510f5667b62e7e84e113e95dffe Reviewed-on: https://go-review.googlesource.com/22358Reviewed-by: Rob Pike <r@golang.org>
-
Rob Pike authored
There should be a unit, and s is the SI unit name, so use that. The other obvious possibility is ns (nanosecond), but the fact that durations are measured in nanoseconds is an internal detail. Fixes #14058. Change-Id: Id1f8f3c77088224d9f7cd643778713d5cc3be5d9 Reviewed-on: https://go-review.googlesource.com/22357Reviewed-by: Robert Griesemer <gri@golang.org>
-
Rob Pike authored
Fixes #14004. $ go doc encoding.gob Before: func Register(value interface{}) func RegisterName(name string, value interface{}) func NewDecoder(r io.Reader) *Decoder func NewEncoder(w io.Writer) *Encoder type CommonType struct { ... } type Decoder struct { ... } type Encoder struct { ... } type GobDecoder interface { ... } type GobEncoder interface { ... } After: func Register(value interface{}) func RegisterName(name string, value interface{}) type CommonType struct { ... } type Decoder struct { ... } func NewDecoder(r io.Reader) *Decoder type Encoder struct { ... } func NewEncoder(w io.Writer) *Encoder type GobDecoder interface { ... } type GobEncoder interface { ... } Change-Id: I021db25bce4a16b3dfa22ab323ca1f4e68d50111 Reviewed-on: https://go-review.googlesource.com/22354Reviewed-by: Robert Griesemer <gri@golang.org>
-
Keith Randall authored
The cached copy's ID is sometimes outside the bounds of the orig array. There's no reason to start at the cached copy and work backwards to the original value. We already have the original value ID at all the callsites. Fixes noopt build Change-Id: I313508a1917e838a87e8cc83b2ef3c2e4a8db304 Reviewed-on: https://go-review.googlesource.com/22355 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Instead of using TARRAY for both arrays and slices, create a new TSLICE kind to handle slices. Also, get rid of the "DDDArray" distinction. While kinda ugly, it seems likely we'll need to defer evaluating the constant bounds expressions for golang.org/issue/13890. Passes toolstash/buildall. Change-Id: I8e45d4900e7df3a04cce59428ec8b38035d3cc3a Reviewed-on: https://go-review.googlesource.com/22329Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
- adjusted example code - fixed comments Fixes #14785. Change-Id: Ia757dc93b0a69b8408559885ece7f3685a37daaa Reviewed-on: https://go-review.googlesource.com/22353Reviewed-by: Rob Pike <r@golang.org>
-
Austin Clements authored
Currently when we compute the trigger for the next GC, we do it based on an estimate of the reachable heap size at the start of the GC cycle, which is itself based on an estimate of the floating garbage. This was introduced by 4655aadd to fix a bad feedback loop that allowed the heap to grow to many times the true reachable size. However, this estimate gets easily confused by rapidly allocating applications, and, worse it's different than the heap size the trigger controller uses to compute the trigger itself. This results in the trigger controller often thinking that GC finished before it started. Since this would be a pretty great outcome from it's perspective, it sets the trigger for the next cycle as close to the next goal as possible (which is limited to 95% of the goal). Furthermore, the bad feedback loop this estimate originally fixed seems not to happen any more, suggesting it was fixed more correctly by some other change in the mean time. Finally, with the change to allocate black, it shouldn't even be theoretically possible for this bad feedback loop to occur. Hence, eliminate the floating garbage estimate and simply consider the reachable heap to be the marked heap. This harms overall throughput slightly for allocation-heavy benchmarks, but significantly improves mutator availability. Fixes #12204. This brings the average trigger in this benchmark from 0.95 (the cap) to 0.7 and the active GC utilization from ~90% to ~45%. Updates #14951. This makes the trigger controller much better behaved, so it pulls the trigger lower if assists are consuming a lot of CPU like it's supposed to, increasing mutator availability. name old time/op new time/op delta XBenchGarbage-12 2.21ms ± 1% 2.28ms ± 3% +3.29% (p=0.000 n=17+17) Some of this slow down we paid for in earlier commits. Relative to the start of the series to switch to allocate-black (the parent of "count black allocations toward scan work"), the garbage benchmark is 2.62% slower. name old time/op new time/op delta BinaryTree17-12 2.53s ± 3% 2.53s ± 3% ~ (p=0.708 n=20+19) Fannkuch11-12 2.08s ± 0% 2.08s ± 0% -0.22% (p=0.002 n=19+18) FmtFprintfEmpty-12 45.3ns ± 2% 45.2ns ± 3% ~ (p=0.505 n=20+20) FmtFprintfString-12 129ns ± 0% 131ns ± 2% +1.80% (p=0.000 n=16+19) FmtFprintfInt-12 121ns ± 2% 121ns ± 2% ~ (p=0.768 n=19+19) FmtFprintfIntInt-12 186ns ± 1% 188ns ± 3% +0.99% (p=0.000 n=19+19) FmtFprintfPrefixedInt-12 188ns ± 1% 188ns ± 1% ~ (p=0.947 n=18+16) FmtFprintfFloat-12 254ns ± 1% 255ns ± 1% +0.30% (p=0.002 n=19+17) FmtManyArgs-12 763ns ± 0% 770ns ± 0% +0.92% (p=0.000 n=18+18) GobDecode-12 7.00ms ± 1% 7.04ms ± 1% +0.61% (p=0.049 n=20+20) GobEncode-12 5.88ms ± 1% 5.88ms ± 0% ~ (p=0.641 n=18+19) Gzip-12 214ms ± 1% 215ms ± 1% +0.43% (p=0.002 n=18+19) Gunzip-12 37.6ms ± 0% 37.6ms ± 0% +0.11% (p=0.015 n=17+18) HTTPClientServer-12 76.9µs ± 2% 78.1µs ± 2% +1.44% (p=0.000 n=20+18) JSONEncode-12 15.2ms ± 2% 15.1ms ± 1% ~ (p=0.271 n=19+18) JSONDecode-12 53.1ms ± 1% 53.3ms ± 0% +0.49% (p=0.000 n=18+19) Mandelbrot200-12 4.04ms ± 1% 4.03ms ± 0% -0.33% (p=0.005 n=18+18) GoParse-12 3.29ms ± 1% 3.28ms ± 1% ~ (p=0.146 n=16+17) RegexpMatchEasy0_32-12 69.9ns ± 3% 69.5ns ± 1% ~ (p=0.785 n=20+19) RegexpMatchEasy0_1K-12 237ns ± 0% 237ns ± 0% ~ (p=1.000 n=18+18) RegexpMatchEasy1_32-12 69.5ns ± 1% 69.2ns ± 1% -0.44% (p=0.020 n=16+19) RegexpMatchEasy1_1K-12 372ns ± 1% 371ns ± 2% ~ (p=0.086 n=20+19) RegexpMatchMedium_32-12 108ns ± 3% 107ns ± 1% -1.00% (p=0.004 n=19+14) RegexpMatchMedium_1K-12 34.2µs ± 4% 34.0µs ± 2% ~ (p=0.380 n=19+20) RegexpMatchHard_32-12 1.77µs ± 4% 1.76µs ± 3% ~ (p=0.558 n=18+20) RegexpMatchHard_1K-12 53.4µs ± 4% 52.8µs ± 2% -1.10% (p=0.020 n=18+20) Revcomp-12 359ms ± 4% 377ms ± 0% +5.19% (p=0.000 n=20+18) Template-12 63.7ms ± 2% 62.9ms ± 2% -1.27% (p=0.005 n=18+20) TimeParse-12 316ns ± 2% 313ns ± 1% ~ (p=0.059 n=20+16) TimeFormat-12 329ns ± 0% 331ns ± 0% +0.39% (p=0.000 n=16+18) [Geo mean] 51.6µs 51.7µs +0.18% Change-Id: I1dce4640c8205d41717943b021039fffea863c57 Reviewed-on: https://go-review.googlesource.com/21324Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we allocate white for most of concurrent marking. This is based on the classical argument that it produces less floating garbage, since allocations during GC may not get linked into the heap and allocating white lets us reclaim these. However, it's not clear how often this actually happens, especially since our write barrier shades any pointer as soon as it's installed in the heap regardless of the color of the slot. On the other hand, allocating black has several advantages that seem to significantly outweigh this downside. 1) It naturally bounds the total scan work to the live heap size at the start of a GC cycle. Allocating white does not, and thus depends entirely on assists to prevent the heap from growing faster than it can be scanned. 2) It reduces the total amount of scan work per GC cycle by the size of newly allocated objects that are linked into the heap graph, since objects allocated black never need to be scanned. 3) It reduces total write barrier work since more objects will already be black when they are linked into the heap graph. This gives a slight overall improvement in benchmarks. name old time/op new time/op delta XBenchGarbage-12 2.24ms ± 0% 2.21ms ± 1% -1.32% (p=0.000 n=18+17) name old time/op new time/op delta BinaryTree17-12 2.60s ± 3% 2.53s ± 3% -2.56% (p=0.000 n=20+20) Fannkuch11-12 2.08s ± 1% 2.08s ± 0% ~ (p=0.452 n=19+19) FmtFprintfEmpty-12 45.1ns ± 2% 45.3ns ± 2% ~ (p=0.367 n=19+20) FmtFprintfString-12 131ns ± 3% 129ns ± 0% -1.60% (p=0.000 n=20+16) FmtFprintfInt-12 122ns ± 0% 121ns ± 2% -0.86% (p=0.000 n=16+19) FmtFprintfIntInt-12 187ns ± 1% 186ns ± 1% ~ (p=0.514 n=18+19) FmtFprintfPrefixedInt-12 189ns ± 0% 188ns ± 1% -0.54% (p=0.000 n=16+18) FmtFprintfFloat-12 256ns ± 0% 254ns ± 1% -0.43% (p=0.000 n=17+19) FmtManyArgs-12 769ns ± 0% 763ns ± 0% -0.72% (p=0.000 n=18+18) GobDecode-12 7.08ms ± 2% 7.00ms ± 1% -1.22% (p=0.000 n=20+20) GobEncode-12 5.88ms ± 0% 5.88ms ± 1% ~ (p=0.406 n=18+18) Gzip-12 214ms ± 0% 214ms ± 1% ~ (p=0.103 n=17+18) Gunzip-12 37.6ms ± 0% 37.6ms ± 0% ~ (p=0.563 n=17+17) HTTPClientServer-12 77.2µs ± 3% 76.9µs ± 2% ~ (p=0.606 n=20+20) JSONEncode-12 15.1ms ± 1% 15.2ms ± 2% ~ (p=0.138 n=19+19) JSONDecode-12 53.3ms ± 1% 53.1ms ± 1% -0.33% (p=0.000 n=19+18) Mandelbrot200-12 4.04ms ± 1% 4.04ms ± 1% ~ (p=0.075 n=19+18) GoParse-12 3.30ms ± 1% 3.29ms ± 1% -0.57% (p=0.000 n=18+16) RegexpMatchEasy0_32-12 69.5ns ± 1% 69.9ns ± 3% ~ (p=0.822 n=18+20) RegexpMatchEasy0_1K-12 237ns ± 1% 237ns ± 0% ~ (p=0.398 n=19+18) RegexpMatchEasy1_32-12 69.8ns ± 2% 69.5ns ± 1% ~ (p=0.090 n=20+16) RegexpMatchEasy1_1K-12 371ns ± 1% 372ns ± 1% ~ (p=0.178 n=19+20) RegexpMatchMedium_32-12 108ns ± 2% 108ns ± 3% ~ (p=0.124 n=20+19) RegexpMatchMedium_1K-12 33.9µs ± 2% 34.2µs ± 4% ~ (p=0.309 n=20+19) RegexpMatchHard_32-12 1.75µs ± 2% 1.77µs ± 4% +1.28% (p=0.018 n=19+18) RegexpMatchHard_1K-12 52.7µs ± 1% 53.4µs ± 4% +1.23% (p=0.013 n=15+18) Revcomp-12 354ms ± 1% 359ms ± 4% +1.27% (p=0.043 n=20+20) Template-12 63.6ms ± 2% 63.7ms ± 2% ~ (p=0.654 n=20+18) TimeParse-12 313ns ± 1% 316ns ± 2% +0.80% (p=0.014 n=17+20) TimeFormat-12 332ns ± 0% 329ns ± 0% -0.66% (p=0.000 n=16+16) [Geo mean] 51.7µs 51.6µs -0.09% Change-Id: I2214a6a0e4f544699ea166073249a8efdf080dc0 Reviewed-on: https://go-review.googlesource.com/21323Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently allocating black switches to the system stack (which is probably a historical accident) and atomically updates the global bytes marked stat. Since we're about to depend on this much more, optimize it a bit by putting it back on the regular stack and updating the per-P bytes marked stat, which gets lazily folded into the global bytes marked stat. Change-Id: Ibbe16e5382d3fd2256e4381f88af342bf7020b04 Reviewed-on: https://go-review.googlesource.com/22170Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently we count black allocations toward the scannable heap size, but not toward the scan work we've done so far. This is clearly inconsistent (we have, in effect, scanned these allocations and since they're already black, we're not going to scan them again). Worse, it means we don't count black allocations toward the scannable heap size as of the *next* GC because this is based on the amount of scan work we did in this cycle. Fix this by counting black allocations as scan work. Currently the GC spends very little time in allocate-black mode, so this probably hasn't been a problem, but this will become important when we switch to always allocating black. Change-Id: If6ff693b070c385b65b6ecbbbbf76283a0f9d990 Reviewed-on: https://go-review.googlesource.com/22119Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Marcel van Lohuizen authored
Allows passing regexps per subtest to --test.run and --test.bench Note that the documentation explicitly states that the split regular expressions match the correpsonding parts (path components) of the bench/test identifier. This is intended and slightly different from the i'th RE matching the subtest/subbench at the respective level. Picking this semantics allows guaranteeing that a test or benchmark identifier as printed by go test can be passed verbatim (possibly quoted) to, respectively, -run or -bench: subtests and subbenches might have a '/' in their name, causing a misaligment if their ID is passed to -run or -bench as is. This semantics has other benefits, but this is the main motivation. Fixes golang.go#15126 Change-Id: If72e6d3f54db1df6bc2729ac6edc7ab3c740e7c3 Reviewed-on: https://go-review.googlesource.com/19122Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Fixes noopt builder. Change-Id: If13373b2597f0fcc9b1b2f9c860f2bd043e43c6c Reviewed-on: https://go-review.googlesource.com/22338Reviewed-by: Keith Randall <khr@golang.org>
-
Cherry Zhang authored
Progress on SSA backend for ARM. Still not complete. It compiles a Fibonacci function, but the caller picked the return value from an incorrect offset. This CL adjusts it to match the stack frame layout for architectures with link register. Updates #15365. Change-Id: I01e03c3e95f5503a185e8ac2b6d9caf4faf3d014 Reviewed-on: https://go-review.googlesource.com/22186Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
Progress on SSA for ARM. Still not complete. Now Fibonacci function compiles and runs correctly. The old backend swaps the operands for CMP instruction. This CL does the same on SSA backend, and uses conditional branch accordingly. Updates #15365. Change-Id: I117e17feb22f03d936608bd232f76970e4bbe21a Reviewed-on: https://go-review.googlesource.com/22187Reviewed-by: Keith Randall <khr@golang.org>
-
David Crawshaw authored
Updates #15374 Change-Id: I3ea715735862fe9550b88d7a29def6cb9d4419a6 Reviewed-on: https://go-review.googlesource.com/22243 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
David Crawshaw authored
Reduces link time for cmd/go by 1%. Change-Id: Iad4a16db0aedc56f81ddf73ba9b632e418dc1b19 Reviewed-on: https://go-review.googlesource.com/22242Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
cmd/link reads PE object files when building programs with cgo. cmd/link accesses object relocations. Add new Section.Relocs that provides similar functionality in debug/pe. Updates #15345 Change-Id: I34de91b7f18cf1c9e4cdb3aedd685486a625ac92 Reviewed-on: https://go-review.googlesource.com/22332 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Keith Randall authored
Disable phielimValue from rewrite pass for now. Change-Id: I9f3bb1f527b50bc7a21cc6b7cb89f6136efd81e8 Reviewed-on: https://go-review.googlesource.com/22335 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-