- 15 May, 2017 7 commits
-
-
David Chase authored
Attaching positions to SB, SP, initial mem can result in less-good line-numbering when compiled for debugging. This "fix" also removes source position from a zero-valued struct (but not from its fields) and from a zero-length array constant. This may be a general problem for constants in entry blocks. Fixes #20367. Change-Id: I7e9df3341be2e2f60f127d35bb31e43cdcfce9a1 Reviewed-on: https://go-review.googlesource.com/43531 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
Enhance the one-live-memory-at-a-time check to run during many more phases of the SSA backend. Also make it work in an interblock fashion. Change types.IsMemory to return true for tuples containing a memory type. Fix trim pass to build the merged phi correctly. Doesn't affect code but allows the check to pass after trim runs. Switch the AddTuple* ops to take the memory-containing tuple argument second. Update #20335 Change-Id: I5b03ef3606b75a9e4f765276bb8b183cdc172b43 Reviewed-on: https://go-review.googlesource.com/43495 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
Updates #19710 Change-Id: I37d19a4a02b9010cb5f9062b3d141d5d65e12e01 Reviewed-on: https://go-review.googlesource.com/43497 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitri Shuralyov authored
Documentation of build.Import says: // If the path is a local import path naming a package that can be imported // using a standard import path, the returned package will set p.ImportPath // to that path. // ... // If an error occurs, Import returns a non-nil error and a non-nil // *Package containing partial information. That behavior was previously untested, and broken by change in CL 33158. Fix that by avoiding returning early on error for local import paths. First, gather partial information, and only then check that the p.Dir directory exists. Add tests for this behavior. Fixes #19769. Fixes #20175 (duplicate of #19769). Updates #17863. Change-Id: I169cb35291099d05e02aaa3cb23a7403d1cc3657 Reviewed-on: https://go-review.googlesource.com/42350Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently proto symbolization uses runtime.FuncForPC and assumes each PC maps to a single frame. This isn't true in the presence of inlining (even with leaf-only inlining this can get incorrect results). Change PC symbolization to use runtime.CallersFrames to expand each PC to all of the frames at that PC. Change-Id: I8d20dff7495a5de495ae07f569122c225d433ced Reviewed-on: https://go-review.googlesource.com/41256 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
-
Austin Clements authored
Proto profile conversion is inconsistent about call vs return PCs in profile locations. The proto defines locations to be call PCs. This is what we do when proto-izing CPU profiles, but we fail to convert the return PCs in memory and count profile stacks to call PCs when converting them to proto locations. Fix this in the heap and count profile conversion functions. TestConvertMemProfile also hard-codes this failure to convert from return PCs to call PCs, so fix up the addresses in the synthesized profile to be return PCs while checking that we get call PCs out of the conversion. Change-Id: If1fc028b86fceac6d71a2d9fa6c41ff442c89296 Reviewed-on: https://go-review.googlesource.com/42951 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
-
Alex Brainman authored
Adjust finddebugruntimepath to look for runtime/debug.go file instead of runtime/runtime.go. This actually finds runtime.GOMAXPROCS in every Go executable (including windows). I also included "-Wl,-T,fix_debug_gdb_scripts.ld" parameter to gcc invocation on windows to work around gcc bug (see #20183 for details). This CL only fixes windows -buildmode=exe, buildmode=c-archive is still broken. Thanks to Egon Elbre and Nick Clifton for investigation. Fixes #20183 Fixes #20218 Change-Id: I5369a4db3913226aef3d9bd6317446856b0a1c34 Reviewed-on: https://go-review.googlesource.com/43331Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 14 May, 2017 3 commits
-
-
Robert Griesemer authored
For #20292. (See discussion in that issue.) Change-Id: I44cd69394fc47a01776905ec34305ba524c89883 Reviewed-on: https://go-review.googlesource.com/43452Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Make yellow the last highlight color rather than the first. Yellow is also the color that Chrome uses to highlight search results, which can be confusing. Also, when Night Shift is on on macOS, yellow highlighting is completely invisible. I suppose should be sleeping instead. Also, remove a completed TODO. Change-Id: I0eb4439272fad9ccb5fe8e2cf409fdd5dc15b26e Reviewed-on: https://go-review.googlesource.com/43463 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
When compiling concurrently, we walk all functions before compiling any of them. Walking functions can cause variables to switch from being non-addrtaken to addrtaken, e.g. to prepare for a runtime call. Typechecking propagates addrtaken-ness of closure variables to their outer variables, so that capturevars can decide whether to pass the variable's value or a pointer to it. When all functions are compiled immediately, as long as the containing function is compiled prior to the closure, this propagation has no effect. When compilation is deferred, though, in rare cases, this results in a change in the addrtaken-ness of a variable in the outer function, which in turn changes the compiler's output. (This is rare because in a great many cases, a temporary has been introduced, insulating the outer variable from modification.) But concurrent compilation must generate identical results. To fix this, track whether capturevars has run. If it has, there is no need to update outer variables when closure variables change. Capturevars always runs before any functions are walked or compiled. The remainder of the changes in this CL are to support the test. In particular, -d=compilelater forces the compiler to walk all functions before compiling any of them, despite being non-concurrent. This is useful because -live is fundamentally incompatible with concurrent compilation, but we want -c=1 to have no behavior changes. Fixes #20250 Change-Id: I89bcb54268a41e8588af1ac8cc37fbef856a90c2 Reviewed-on: https://go-review.googlesource.com/42853 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
- 13 May, 2017 3 commits
-
-
wuyunzhou authored
Change-Id: I6c210e0c23ca533e1f303f88ef9dcb629a294a2a Reviewed-on: https://go-review.googlesource.com/43472Reviewed-by: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org>
-
Brad Fitzpatrick authored
Fixes #20325 Change-Id: Ie363fef73d0deae40af41ee3f4403ad18546eba6 Reviewed-on: https://go-review.googlesource.com/43460 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Lars Jeppesen authored
When writing tar files by using the FileInfoHeader the type bits was set in the mode field of the header This is not correct according to the standard (GNU/Posix) and other implementations. Fixed #20150 Change-Id: I3be7d946a1923ad5827cf45c696546a5e287ebba Reviewed-on: https://go-review.googlesource.com/42093Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 12 May, 2017 7 commits
-
-
Robert Griesemer authored
While at it, unindent source text so column values are easier to read, remove unnecessary text in output, and simplify the loop. Fixes #20346. Change-Id: I0fde02b9e4242383da427f4cf4c6c13dd0ab3b47 Reviewed-on: https://go-review.googlesource.com/43450 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matt Harden authored
In some cases it is desirable to customize the way the DNS server is contacted, for instance to use a specific LocalAddr. While most operating-system level resolvers do not allow this, we have the opportunity to do so with the Go resolver. Most of the code was already in place to allow tests to override the dialer. This exposes that functionality, and as a side effect eliminates the need for a testing hook. Fixes #17404 Change-Id: I1c5e570f8edbcf630090f8ec6feb52e379e3e5c0 Reviewed-on: https://go-review.googlesource.com/37260 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
runtime.gchelper depends on the non-atomic load of work.ndone happening strictly before the atomic add of work.nwait. Until very recently (commit 978af9c2, fixing #20334), the compiler reordered these operations. This created a race since work.ndone can change as soon as work.nwait is equal to work.ndone. If that happened, more than one gchelper could attempt to wake up the work.alldone note, causing a "double wakeup" panic. This was fixed in the compiler, but to make this code less subtle, make the load of work.ndone atomic. This clearly forces the order of these operations, ensuring the race doesn't happen. Fixes #19305 (though really 978af9c2 fixed it). Change-Id: Ieb1a84e1e5044c33ac612c8a5ab6297e7db4c57d Reviewed-on: https://go-review.googlesource.com/43311 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
This adds debugging information when we panic with "heapBitsForSpan: base out of range". Updates #20259. Change-Id: I0dc1a106aa9e9531051c7d08867ace5ef230eb3f Reviewed-on: https://go-review.googlesource.com/43310 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Ian Lance Taylor authored
On Windows the drive letter is sometime "c:" and sometimes "C:". Fixes #20336. Change-Id: I38c86999af9522c51470d60016729d41cfec6b25 Reviewed-on: https://go-review.googlesource.com/43390 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Hiroshi Ioka authored
Change-Id: If7329b81073d7c98fdcb8a2c0b35f8708000606e Reviewed-on: https://go-review.googlesource.com/43332 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Hiroshi Ioka authored
TestCgoContainsSpace builds a small program which mimics $CC. Usually, $CC attempts to compile a trivial code to detect its own supported flags (i.e. "-no-pie", which must be passed on some systems), however the mimic didn't consider these cases. This CL solve the issue. Also, use the same name as $CC, it may solve other potential problems. Fixes #20324 Change-Id: I7a00ac016a5fd0667540f2a715371f8152edc395 Reviewed-on: https://go-review.googlesource.com/43330Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 11 May, 2017 7 commits
-
-
Keith Randall authored
Tuple ops are weird. They are essentially a pair of ops, one which consumes a mem and one which generates a mem (the Select1). The schedule pass didn't handle these quite right. Fix the scheduler to include both parts of the paired op in the store chain. That makes sure that loads are correctly ordered with respect to the first of the pair. Add a check for the ssacheck builder, that there is only one live store at a time. I thought we already had such a check, but apparently not... Fixes #20335 Change-Id: I59eb3446a329100af38d22820b1ca2190ca46a78 Reviewed-on: https://go-review.googlesource.com/43294 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
The switch to detailed position information broke the removal of duplicate panics on the same line. Restore it. Neutral compiler performance impact: name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.8MB ± 0% ~ (p=0.690 n=5+5) Unicode 28.7MB ± 0% 28.7MB ± 0% +0.13% (p=0.032 n=5+5) GoTypes 109MB ± 0% 109MB ± 0% ~ (p=1.000 n=5+5) Compiler 457MB ± 0% 457MB ± 0% ~ (p=0.151 n=5+5) SSA 1.09GB ± 0% 1.10GB ± 0% +0.17% (p=0.008 n=5+5) Flate 24.6MB ± 0% 24.5MB ± 0% -0.35% (p=0.008 n=5+5) GoParser 30.9MB ± 0% 31.0MB ± 0% ~ (p=0.421 n=5+5) Reflect 73.4MB ± 0% 73.4MB ± 0% ~ (p=0.056 n=5+5) Tar 25.6MB ± 0% 25.5MB ± 0% -0.61% (p=0.008 n=5+5) XML 40.9MB ± 0% 40.9MB ± 0% ~ (p=0.841 n=5+5) [Geo mean] 71.6MB 71.6MB -0.07% name old allocs/op new allocs/op delta Template 394k ± 0% 395k ± 1% ~ (p=0.151 n=5+5) Unicode 343k ± 0% 344k ± 0% +0.38% (p=0.032 n=5+5) GoTypes 1.16M ± 0% 1.16M ± 0% ~ (p=1.000 n=5+5) Compiler 4.41M ± 0% 4.42M ± 0% ~ (p=0.151 n=5+5) SSA 9.79M ± 0% 9.79M ± 0% ~ (p=0.690 n=5+5) Flate 238k ± 1% 238k ± 0% ~ (p=0.151 n=5+5) GoParser 321k ± 0% 321k ± 1% ~ (p=0.548 n=5+5) Reflect 958k ± 0% 957k ± 0% ~ (p=0.841 n=5+5) Tar 252k ± 0% 252k ± 1% ~ (p=0.151 n=5+5) XML 401k ± 0% 400k ± 0% ~ (p=1.000 n=5+5) [Geo mean] 741k 742k +0.08% Reduces object files a little bit: name old object-bytes new object-bytes delta Template 386k ± 0% 386k ± 0% -0.04% (p=0.008 n=5+5) Unicode 202k ± 0% 202k ± 0% ~ (all equal) GoTypes 1.16M ± 0% 1.16M ± 0% -0.04% (p=0.008 n=5+5) Compiler 3.91M ± 0% 3.91M ± 0% -0.08% (p=0.008 n=5+5) SSA 7.91M ± 0% 7.91M ± 0% -0.04% (p=0.008 n=5+5) Flate 228k ± 0% 227k ± 0% -0.28% (p=0.008 n=5+5) GoParser 283k ± 0% 283k ± 0% -0.01% (p=0.008 n=5+5) Reflect 952k ± 0% 951k ± 0% -0.03% (p=0.008 n=5+5) Tar 188k ± 0% 187k ± 0% -0.09% (p=0.008 n=5+5) XML 406k ± 0% 406k ± 0% -0.04% (p=0.008 n=5+5) [Geo mean] 648k 648k -0.06% This was discovered in the context for the Fannkuch benchmark. It shrinks the number of panicindex calls in that function from 13 back to 9, their 1.8.1 level. It shrinks the function text a bit, from 829 to 801 bytes. It slows down execution a little, presumably due to alignment (?). name old time/op new time/op delta Fannkuch11-8 2.68s ± 2% 2.74s ± 1% +2.09% (p=0.000 n=19+20) After this CL, 1.8.1 and tip are identical: name old time/op new time/op delta Fannkuch11-8 2.74s ± 2% 2.74s ± 1% ~ (p=0.301 n=20+20) Fixes #20332 Change-Id: I2aeacc3e8cf2ac1ff10f36c572a27856f4f8f7c9 Reviewed-on: https://go-review.googlesource.com/43291 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
The writebarrier test has to change. Now that T23 composite literals are passed to the backend, they get SSA'd, so writes to their fields are treated separately, so the relevant part of the first write to t23 is now a dead store. Preserve the intent of the test by splitting it up into two functions. Reduces code size a bit: name old object-bytes new object-bytes delta Template 386k ± 0% 386k ± 0% ~ (all equal) Unicode 202k ± 0% 202k ± 0% ~ (all equal) GoTypes 1.16M ± 0% 1.16M ± 0% ~ (all equal) Compiler 3.92M ± 0% 3.91M ± 0% -0.19% (p=0.008 n=5+5) SSA 7.91M ± 0% 7.91M ± 0% ~ (all equal) Flate 228k ± 0% 228k ± 0% -0.05% (p=0.008 n=5+5) GoParser 283k ± 0% 283k ± 0% ~ (all equal) Reflect 952k ± 0% 952k ± 0% -0.06% (p=0.008 n=5+5) Tar 188k ± 0% 188k ± 0% -0.09% (p=0.008 n=5+5) XML 406k ± 0% 406k ± 0% -0.02% (p=0.008 n=5+5) [Geo mean] 649k 648k -0.04% Fixes #18872 Change-Id: Ifeed0f71f13849732999aa731cc2bf40c0f0e32a Reviewed-on: https://go-review.googlesource.com/43154 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
Fixes #20333 Change-Id: I0653cc859076f146d8ea8f5bd55cb22b0b8d987f Reviewed-on: https://go-review.googlesource.com/43290 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tom Bergan authored
Updates #18318 Change-Id: Ibd4ebc7708abf87eded8da9661378b5777b8a400 Reviewed-on: https://go-review.googlesource.com/43231 Run-TryBot: Tom Bergan <tombergan@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ben Shi authored
Both Keith's https://go-review.googlesource.com/c/41612/ and and Ben's https://go-review.googlesource.com/c/41679/ optimized ARM's constant pool. But neither was complete. First, BIC was forgotten. 1. "BIC $0xff00ff00, Reg" can be optimized to "BIC $0xff000000, Reg BIC $0x0000ff00, Reg" 2. "BIC $0xffff00ff, Reg" can be optimized to "AND $0x0000ff00, Reg" 3. "AND $0xffff00ff, Reg" can be optimized to "BIC $0x0000ff00, Reg" Second, break a non-ARMImmRot to the subtraction of two ARMImmRots was left as TODO. 1. "ADD $0x00fffff0, Reg" can be optimized to "ADD $0x01000000, Reg SUB $0x00000010, Reg" 2. "SUB $0x00fffff0, Reg" can be optimized to "SUB $0x01000000, Reg ADD $0x00000010, Reg" This patch fixes them and issue #19844. The go1 benchmark shows improvements. name old time/op new time/op delta BinaryTree17-4 41.4s ± 1% 41.7s ± 1% +0.54% (p=0.000 n=50+49) Fannkuch11-4 24.7s ± 1% 25.1s ± 0% +1.70% (p=0.000 n=50+49) FmtFprintfEmpty-4 853ns ± 1% 852ns ± 1% ~ (p=0.833 n=50+50) FmtFprintfString-4 1.33µs ± 1% 1.33µs ± 1% ~ (p=0.163 n=50+50) FmtFprintfInt-4 1.40µs ± 1% 1.40µs ± 0% ~ (p=0.293 n=50+35) FmtFprintfIntInt-4 2.09µs ± 1% 2.08µs ± 1% -0.39% (p=0.000 n=50+49) FmtFprintfPrefixedInt-4 2.43µs ± 1% 2.43µs ± 1% ~ (p=0.552 n=50+50) FmtFprintfFloat-4 4.57µs ± 1% 4.42µs ± 1% -3.18% (p=0.000 n=50+50) FmtManyArgs-4 8.62µs ± 1% 8.52µs ± 0% -1.08% (p=0.000 n=50+50) GobDecode-4 101ms ± 1% 101ms ± 2% +0.45% (p=0.001 n=49+49) GobEncode-4 90.7ms ± 1% 91.1ms ± 2% +0.51% (p=0.001 n=50+50) Gzip-4 4.23s ± 1% 4.21s ± 1% -0.62% (p=0.000 n=50+50) Gunzip-4 623ms ± 1% 619ms ± 0% -0.63% (p=0.000 n=50+42) HTTPClientServer-4 721µs ± 5% 683µs ± 3% -5.25% (p=0.000 n=50+47) JSONEncode-4 251ms ± 1% 253ms ± 1% +0.54% (p=0.000 n=49+50) JSONDecode-4 941ms ± 1% 944ms ± 1% +0.30% (p=0.001 n=49+50) Mandelbrot200-4 49.3ms ± 1% 49.3ms ± 0% ~ (p=0.918 n=50+48) GoParse-4 47.1ms ± 1% 47.2ms ± 1% +0.18% (p=0.025 n=50+50) RegexpMatchEasy0_32-4 1.23µs ± 1% 1.24µs ± 1% +0.30% (p=0.000 n=49+50) RegexpMatchEasy0_1K-4 7.74µs ± 7% 7.76µs ± 5% ~ (p=0.888 n=50+50) RegexpMatchEasy1_32-4 1.32µs ± 1% 1.32µs ± 1% +0.23% (p=0.003 n=50+50) RegexpMatchEasy1_1K-4 10.6µs ± 2% 10.5µs ± 3% -1.29% (p=0.000 n=49+50) RegexpMatchMedium_32-4 2.19µs ± 1% 2.10µs ± 1% -3.79% (p=0.000 n=49+49) RegexpMatchMedium_1K-4 544µs ± 0% 545µs ± 0% ~ (p=0.123 n=41+50) RegexpMatchHard_32-4 28.8µs ± 0% 28.8µs ± 1% ~ (p=0.580 n=46+50) RegexpMatchHard_1K-4 863µs ± 1% 865µs ± 1% +0.31% (p=0.027 n=47+50) Revcomp-4 82.2ms ± 2% 82.3ms ± 2% ~ (p=0.894 n=48+49) Template-4 1.06s ± 1% 1.04s ± 1% -1.18% (p=0.000 n=50+49) TimeParse-4 7.25µs ± 1% 7.35µs ± 0% +1.48% (p=0.000 n=50+50) TimeFormat-4 13.3µs ± 1% 13.2µs ± 1% -0.13% (p=0.007 n=50+50) [Geo mean] 736µs 733µs -0.37% name old speed new speed delta GobDecode-4 7.60MB/s ± 1% 7.56MB/s ± 2% -0.46% (p=0.001 n=49+49) GobEncode-4 8.47MB/s ± 1% 8.42MB/s ± 2% -0.50% (p=0.001 n=50+50) Gzip-4 4.58MB/s ± 1% 4.61MB/s ± 1% +0.59% (p=0.000 n=50+50) Gunzip-4 31.2MB/s ± 1% 31.4MB/s ± 0% +0.63% (p=0.000 n=50+42) JSONEncode-4 7.73MB/s ± 1% 7.69MB/s ± 1% -0.53% (p=0.000 n=49+50) JSONDecode-4 2.06MB/s ± 1% 2.06MB/s ± 1% ~ (p=0.052 n=44+50) GoParse-4 1.23MB/s ± 0% 1.23MB/s ± 2% ~ (p=0.526 n=26+50) RegexpMatchEasy0_32-4 25.9MB/s ± 1% 25.9MB/s ± 1% -0.30% (p=0.000 n=49+50) RegexpMatchEasy0_1K-4 132MB/s ± 7% 132MB/s ± 6% ~ (p=0.885 n=50+50) RegexpMatchEasy1_32-4 24.2MB/s ± 1% 24.1MB/s ± 1% -0.22% (p=0.003 n=50+50) RegexpMatchEasy1_1K-4 96.4MB/s ± 2% 97.8MB/s ± 3% +1.36% (p=0.000 n=50+50) RegexpMatchMedium_32-4 460kB/s ± 0% 476kB/s ± 1% +3.43% (p=0.000 n=49+50) RegexpMatchMedium_1K-4 1.88MB/s ± 0% 1.88MB/s ± 0% ~ (all equal) RegexpMatchHard_32-4 1.11MB/s ± 0% 1.11MB/s ± 1% +0.34% (p=0.000 n=45+50) RegexpMatchHard_1K-4 1.19MB/s ± 1% 1.18MB/s ± 1% -0.34% (p=0.033 n=50+50) Revcomp-4 30.9MB/s ± 2% 30.9MB/s ± 2% ~ (p=0.894 n=48+49) Template-4 1.84MB/s ± 1% 1.86MB/s ± 2% +1.19% (p=0.000 n=48+50) [Geo mean] 6.63MB/s 6.65MB/s +0.26% Fixes #19844. Change-Id: I5ad16cc0b29267bb4579aca3dcc10a0b8ade1aa4 Reviewed-on: https://go-review.googlesource.com/42430 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Daniel Martí authored
v is not a pointer receiver, and v.typ isn't used in the lines below. The assignment is dead. Remove it. Keep the comment, as it refers to the whole case block and not just the removed line. Change-Id: Icb2d20c287d9a41bf620ebe5cdec764cd84178a7 Reviewed-on: https://go-review.googlesource.com/43134 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 10 May, 2017 13 commits
-
-
Ian Lance Taylor authored
Change-Id: I73674a90d88da630b09dcb75ced5d9f0d96c3c09 Reviewed-on: https://go-review.googlesource.com/43153 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Chase authored
Inadvertent copy-pasta in CL https://go-review.googlesource.com/c/36207/ Is this allowed for 1.9 post-freeze? Change-Id: I00dd27f9f53babeded3695346986a7a491f8a771 Reviewed-on: https://go-review.googlesource.com/43092 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
They are not exported and not used in the compiler or standard library. Change-Id: Ie1d210464f826742d282f12258ed1792cbd2d188 Reviewed-on: https://go-review.googlesource.com/43135 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
Fixes #20316 Change-Id: I2553ad9a82dfcb30f020c2a3e37b868111425a20 Reviewed-on: https://go-review.googlesource.com/43151 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Chase authored
Reuse block head or preceding instruction's line number for register allocator's spill, fill, copy, rematerialization instructionsl; and also for phi, and for no-src-pos instructions. Assembler creates same line number tables for copy-predecessor-line and for no-src-pos, but copy-predecessor produces better-looking assembly language output with -S and with GOSSAFUNC, and does not require changes to tests of existing assembly language. Split "copyInto" into two cases, one for register allocation, one for otherwise. This caused the test score line change count to increase by one, which may reflect legitimately useful information preserved. Without any special treatment for copyInto, the change count increases by 21 more, from 51 to 72 (i.e., quite a lot). There is a test; using two naive "scores" for line number churn, the old numbering is 2x or 4x worse. Fixes #18902. Change-Id: I0a0a69659d30ee4e5d10116a0dd2b8c5df8457b1 Reviewed-on: https://go-review.googlesource.com/36207 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Hiroshi Ioka authored
Fixes #7906 Change-Id: Ibcf9cd670593241921ab3c426ff7357f799ebc3e Reviewed-on: https://go-review.googlesource.com/43072Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
Implements detection of x86 cpu features that are used in the go standard library. Changes all standard library packages to use the new cpu package instead of using runtime internal variables to check x86 cpu features. Updates: #15403 Change-Id: I2999a10cb4d9ec4863ffbed72f4e021a1dbc4bb9 Reviewed-on: https://go-review.googlesource.com/41476Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Eliminates stores of values that have just been loaded from the same location. Handles the common case where there are up to 3 intermediate stores to non-overlapping struct fields. For example the loads and stores of x.a, x.b and x.d in the following function are now removed: type T struct { a, b, c, d int } func f(x *T) { y := *x y.c += 8 *x = y } Before this CL (s390x): TEXT "".f(SB) MOVD "".x(R15), R5 MOVD (R5), R1 MOVD 8(R5), R2 MOVD 16(R5), R0 MOVD 24(R5), R4 ADD $8, R0, R3 STMG R1, R4, (R5) RET After this CL (s390x): TEXT "".f(SB) MOVD "".x(R15), R1 MOVD 16(R1), R0 ADD $8, R0, R0 MOVD R0, 16(R1) RET In total these rules are triggered ~5091 times during all.bash, which is broken down as: Intermediate stores | Triggered --------------------+---------- 0 | 1434 1 | 2508 2 | 888 3 | 261 --------------------+---------- Change-Id: Ia4721ae40146aceec1fdd3e65b0e9283770bfba5 Reviewed-on: https://go-review.googlesource.com/38793 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Michael Munday authored
The files PPC64.rules and rewritePPC64.go were out of sync due to conflicts between CL 41630 and CL 42145 (i.e. running 'go run *.go' in the gen directory resulted in unexpected changes). Change-Id: I1d409656b66afeab6cb9c6df9b3dcab7859caa75 Reviewed-on: https://go-review.googlesource.com/43091 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
David Chase authored
This can make life easier for Delve (and other debuggers), and can help them with bug reports. Sample producer field (from objdump): <48> DW_AT_producer : Go cmd/compile devel +8a59dbf41a Mon May 8 16:02:44 2017 -0400 Change-Id: I0605843c959b53a60a25a3b870aa8755bf5d5b13 Reviewed-on: https://go-review.googlesource.com/33588 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
We do a division by the elem type size to check if the array size would be too large for the virtual address space. This is a silly check if the size is 0, but the problem is that it means a division by zero and a panic. Since arrays of empty structs are valid in a regular program, make them also work in reflect. Use a separate, explicit test with struct{}{} to make sure the test for a zero-sized type is not confused with the rest. Fixes #20313. Change-Id: I47b8b87e6541631280b79227bdea6a0f6035c9e0 Reviewed-on: https://go-review.googlesource.com/43131 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Lynn Boger authored
This adds math/bits intrinsics for OnesCount, Len, TrailingZeros on ppc64x. benchmark old ns/op new ns/op delta BenchmarkLeadingZeros-16 4.26 1.71 -59.86% BenchmarkLeadingZeros16-16 3.04 1.83 -39.80% BenchmarkLeadingZeros32-16 3.31 1.82 -45.02% BenchmarkLeadingZeros64-16 3.69 1.71 -53.66% BenchmarkTrailingZeros-16 2.55 1.62 -36.47% BenchmarkTrailingZeros32-16 2.55 1.77 -30.59% BenchmarkTrailingZeros64-16 2.78 1.62 -41.73% BenchmarkOnesCount-16 3.19 0.93 -70.85% BenchmarkOnesCount32-16 2.55 1.18 -53.73% BenchmarkOnesCount64-16 3.22 0.93 -71.12% Update #18616 I also made a change to bits_test.go because when debugging some failures the output was not quite providing the right argument information. Change-Id: Ia58d31d1777cf4582a4505f85b11a1202ca07d3e Reviewed-on: https://go-review.googlesource.com/41630 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Daniel Martí authored
When constructing a new type for an array type in ArrayOf, we don't reset tflag to 0. All the other methods in the package, such as SliceOf, do this already. This results in the new array type having weird issues when being printed, such as having tflagExtraStar set when it shouldn't. That flag removes the first char to get rid of '*', but when used incorrectly in this case it eats the '[' character leading to broken strings like "3]int". This was fixed in 56752eb2 for issue #16722, but ArrayOf was missed. Also make the XM test struct have a non-zero size as that leads to a division by zero panic in ArrayOf. Fixes #20311. Change-Id: I18f1027fdbe9f71767201e7424269c3ceeb23eb5 Reviewed-on: https://go-review.googlesource.com/43130 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-