- 09 Oct, 2016 1 commit
-
-
Emmanuel Odeke authored
Fixes #17374. Change-Id: Ic89c35aaa31f35a8a4e3ffa09f49b68f08127625 Reviewed-on: https://go-review.googlesource.com/30718Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
- 08 Oct, 2016 2 commits
-
-
Mikio Hara authored
Updates golang_org/x/net/lif to rev 084869a for: - lif: rename internal types and constants generated by cgo Change-Id: Icf478d60f5ef35800966c62dcf046f7fe50204ff Reviewed-on: https://go-review.googlesource.com/30731 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Updates golang_org/x/net/route to rev f09c466 for: - route: fix typo - route: test helper code cleanup Change-Id: If39f0e947dc56f3b0f38190035d2f47c8d847c74 Reviewed-on: https://go-review.googlesource.com/30730 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 07 Oct, 2016 11 commits
-
-
Michael Munday authored
TESTB was implemented as AND $0xff, Rx, REGTMP. Unfortunately there is no 3-operand AND-with-immediate instruction and so it was emulated by the assembler using two instructions. This CL uses CMPW instead of AND and also optimizes CMPW to use the chi instruction where possible. Overall this CL reduces the size of the .text section of the bin/go binary by ~2%. Change-Id: Ic335c29fc1129378fcbb1265bfb10f5b744a0f3f Reviewed-on: https://go-review.googlesource.com/30690 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
No need to build a bespoke dom tree here when we might have one cached already. The allocations for the dom tree were also more expensive than they needed to be. Fixes #12021 Change-Id: I6a967880aee03660ad6fc293f8fc783779cae11d Reviewed-on: https://go-review.googlesource.com/30671 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Andrew Pogrebnoy authored
The algorithm for placing a phi nodes in small functions now unreachable. This patch fix that. Change-Id: I253d745b414fa12ee0719459c28e78a69c6861ae Reviewed-on: https://go-review.googlesource.com/30106 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
Currently these are labeled "MARK", which was accurate in the STW collector, but these really indicate mark termination now, since marking happens for the full duration of the concurrent GC. Re-label them as "MARK TERMINATION" to clarify this. Change-Id: Ie98bd961195acde49598b4fa3f9e7d90d757c0a6 Reviewed-on: https://go-review.googlesource.com/30018Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
Currently, the process-wide GC state is attributed to the P that happened to perform the allocation that exceeded the GC trigger. This is pretty arbitrary and makes it hard to see when GC is running since the GC spans are intermingled with a lot of other trace noise. The current display is particularly confusing because it creates three sub-rows in the P row that can overlap each other. Usually a P has just two sub-rows: one showing the current G and another showing that G's activity. However, because GC is attributed to a proc, it winds up as a third row that neither subsumes nor is subsumed by any other row. This in turn screws up the trace's layout and results in overlapping events. Fix these problems by creating a new dedicated row like the existing "Network" and "Timer" rows and displaying process-wide GC events in this row. Mark termination and sweep events still appear in their respective P rows because these are meaningfully attributed. Change-Id: Ie1a1c6cf8c446e4b043f10f3968f91ff1b546d15 Reviewed-on: https://go-review.googlesource.com/30017Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Austin Clements authored
When GC is disabled, we set gcpercent to -1. However, we still use gcpercent to compute several values, such as next_gc and gc_trigger. These calculations are meaningless when gcpercent is -1 and result in meaningless values. This is okay in a sense because we also never use these values if gcpercent is -1, but they're confusing when exposed to the user, for example via MemStats or the execution trace. It's particularly unfortunate in the execution trace because it attempts to plot the underflowed value of next_gc, which scales all useful information in the heap row into oblivion. Fix this by making next_gc ^0 when gcpercent < 0. This has the advantage of being true in a way: next_gc is effectively infinite when gcpercent < 0. We can also detect this special value when updating the execution trace and report next_gc as 0 so it doesn't blow up the display of the heap line. Change-Id: I4f366e4451f8892a4908da7b2b6086bdc67ca9a9 Reviewed-on: https://go-review.googlesource.com/30016Reviewed-by: Rick Hudson <rlh@golang.org>
-
Keith Randall authored
Not sure why it was ever disabled (early SSA work?) but it passes now. Change-Id: I76439cacdbd286ce077f7e08c4d0663396a0cd8f Reviewed-on: https://go-review.googlesource.com/30672Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
No point doing this check all the time. Fixes #15621 Change-Id: I1966c061986fe98fe9ebe146d6b9738c13cef724 Reviewed-on: https://go-review.googlesource.com/30670Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
This CL makes minor adjustment to the handling of spaces and newlines and then documents the result. The semantic adjustment mainly concerns the handling of a run of spaces following a newline in the format, like in "\n ". Previously, that run of spaces was ignored entirely, leading to paradoxes like the format "1 \n 2" not matching itself as input. Now, spaces following a newline in the format match zero or more spaces following the corresponding newline in the input. The changes to the test suite show how minor the semantic adjustments are and how they make the behavior more regular than previously. This CL also updates the documentation to explain the handling of spaces more precisely, incorporating the draft from CL 17723 but describing the newly introduced behavior. Fixes #13565. Change-Id: I129666e9ba42de3c28b67f75cb47488e9a4c1867 Reviewed-on: https://go-review.googlesource.com/30611Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
There are no semantic changes here, just tests to establish the status quo. A followup CL will make some semantic changes, the (limited) scope of which should be clear from the number of tests that change. For #13565. Change-Id: I960749cf59d4dfe39c324875bcc575096654f883 Reviewed-on: https://go-review.googlesource.com/30610 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Anonymous pointer and slice types are very common and identical anyway, so just reuse them rather than allocating new ones everywhere they appear. Turns out to be a small code/stack size win because SSA relies on gc.Type identity for reusing temporary stack slots: text data bss dec hex filename 6453005 231643 146328 6830976 683b80 go.old 6446660 231643 146328 6824631 6822b7 go.new Saves on memory usage during compile time too, and maybe a small CPU time win, but the benchmarks are pretty noisy: name old time/op new time/op delta Template 342ms ± 8% 339ms ± 9% ~ (p=0.332 n=99+99) Unicode 183ms ± 9% 181ms ±11% ~ (p=0.274 n=95+98) GoTypes 1.05s ± 4% 1.04s ± 3% -1.22% (p=0.000 n=97+95) Compiler 4.49s ± 7% 4.46s ± 6% ~ (p=0.058 n=96+91) name old user-ns/op new user-ns/op delta Template 520M ±17% 522M ±20% ~ (p=0.544 n=98+100) Unicode 331M ±27% 327M ±30% ~ (p=0.615 n=98+98) GoTypes 1.54G ±10% 1.53G ±12% ~ (p=0.173 n=99+100) Compiler 6.33G ±10% 6.33G ±10% ~ (p=0.682 n=98+98) name old alloc/op new alloc/op delta Template 44.5MB ± 0% 44.1MB ± 0% -0.80% (p=0.000 n=97+99) Unicode 37.5MB ± 0% 37.3MB ± 0% -0.44% (p=0.000 n=98+100) GoTypes 126MB ± 0% 124MB ± 0% -1.41% (p=0.000 n=98+99) Compiler 518MB ± 0% 508MB ± 0% -1.90% (p=0.000 n=98+100) name old allocs/op new allocs/op delta Template 441k ± 0% 434k ± 0% -1.76% (p=0.000 n=100+97) Unicode 368k ± 0% 365k ± 0% -0.69% (p=0.000 n=99+99) GoTypes 1.26M ± 0% 1.23M ± 0% -2.27% (p=0.000 n=100+99) Compiler 4.60M ± 0% 4.46M ± 0% -2.96% (p=0.000 n=100+99) Change-Id: I94abce5c57aed0f9c48f567b3ac24c627d4c7c91 Reviewed-on: https://go-review.googlesource.com/30632 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 06 Oct, 2016 22 commits
-
-
Ian Lance Taylor authored
On 64-bit big-endian GNU/Linux machines we need to treat sigset as a single uint64, not as a pair of uint32 values. This fix was already made for s390x, but not for ppc64 (which is big-endian--the little endian version is known as ppc64le). So copy os_linux_390.x to os_linux_be64.go, and use build constraints as needed. Fixes #17361 Change-Id: Ia0eb18221a8f5056bf17675fcfeb010407a13fb0 Reviewed-on: https://go-review.googlesource.com/30602 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
This simply documents the status quo accepted by cmd/compile, gccgo, and go/types. The new language matches the language used for indices of index expressions for arrays and slices. Fixes #16679. Change-Id: I65447889fbda9d222f2a9e6c10334d1b38c555f0 Reviewed-on: https://go-review.googlesource.com/30474Reviewed-by: Rob Pike <r@golang.org>
-
Robert Griesemer authored
Also, document behavior explicitly for all SetString implementations. Fixes #17001. Change-Id: Iccc882b4bc7f8b61b6092f330e405c146a80dc98 Reviewed-on: https://go-review.googlesource.com/30472Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Brad Fitzpatrick authored
Updates #17366 Change-Id: Ia4bd3c74c48b85f186586184a7c2b66d3b80fc9c Reviewed-on: https://go-review.googlesource.com/30596 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Alexander Döring authored
Updates #16360 Change-Id: I941519981ff5bda3a113e14fa6be718eb4d2bf83 Reviewed-on: https://go-review.googlesource.com/30554 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #15247 Change-Id: I942fb2eacd1b54bab66cc147a6b047a3ffce0b84 Reviewed-on: https://go-review.googlesource.com/30595Reviewed-by: Russ Cox <rsc@golang.org>
-
Yasuhiro Matsumoto authored
Handle NTFS timestamp, UNIX timestamp, Extended extra timestamp. Writer supports only Extended extra timestamp field, matching most zip creators. Fixes #10242. Change-Id: Id665db274e63def98659231391fb77392267ac1e Reviewed-on: https://go-review.googlesource.com/18274 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Munday authored
We insert extensions when lowering comparisons and they were blocking constant folding. Change-Id: I804bbf91c7606612ffe921a90853844a57e55955 Reviewed-on: https://go-review.googlesource.com/30541Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Simon Rawet authored
AddDate now retrieves location from t.Location() to ensure that it never calls Date with a nil location. Added test for this bug on all Time's methods Fixes #15852 Change-Id: Id2a222af56993f741ad0b802a2c3b89e8e463926 Reviewed-on: https://go-review.googlesource.com/23561Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
David Chase authored
It tests the behavior of the old deleted compiler. Fixes #17362. Change-Id: Ia2fdec734c5cbe724a9de562ed71598f67244ab3 Reviewed-on: https://go-review.googlesource.com/30593Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Hajime Hoshi authored
Change-Id: Id2a9fc1e9e70eaf5f25ddc7476061e06abcf60e4 Reviewed-on: https://go-review.googlesource.com/30573Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Fixes #17281. Change-Id: I4e639998dbe3baa98879f1becc37d7c4d19351e7 Reviewed-on: https://go-review.googlesource.com/30473Reviewed-by: Alan Donovan <adonovan@google.com>
-
Cherry Zhang authored
Fixes #17354. Change-Id: I0e018c8c3e791fc6cc1925dbbc18c2151ba9a111 Reviewed-on: https://go-review.googlesource.com/30539 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Using 387 mode was computing it without underflow to zero, apparently due to an 80-bit intermediate. Avoid underflow even with 64-bit floats. This eliminates the TODOs in the test suite. Fixes linux-386-387 build and fixes #11441. Change-Id: I8abaa63bfdf040438a95625d1cb61042f0302473 Reviewed-on: https://go-review.googlesource.com/30540 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Richard Gibson authored
Struct fields can be suppressed in JSON serialization by "-" tags, but that doesn't preclude generation of "-" object keys. Document and verify the mechanism for doing so. Change-Id: I7f60e1759cfee15cb7b2447cd35fab91c5b004e6 Reviewed-on: https://go-review.googlesource.com/21204 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
Deletes the following s390x instructions: - ADDME - ADDZE - SUBME - SUBZE They appear to be emulated PPC instructions left over from the porting process and I don't think they will ever be useful. Change-Id: I9b1ba78019dbd1218d0c8f8ea2903878802d1990 Reviewed-on: https://go-review.googlesource.com/30538 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Denis Nagorny authored
Use AVX if available on 4th generation of Intel(TM) Core(TM) processors. (collected on E5 2609v3 @1.9GHz) name old speed new speed delta Memmove/1-6 158MB/s ± 0% 172MB/s ± 0% +9.09% (p=0.000 n=16+16) Memmove/2-6 316MB/s ± 0% 345MB/s ± 0% +9.09% (p=0.000 n=18+16) Memmove/3-6 517MB/s ± 0% 517MB/s ± 0% ~ (p=0.445 n=16+16) Memmove/4-6 687MB/s ± 1% 690MB/s ± 0% +0.35% (p=0.000 n=20+17) Memmove/5-6 729MB/s ± 0% 729MB/s ± 0% +0.01% (p=0.000 n=16+18) Memmove/6-6 875MB/s ± 0% 875MB/s ± 0% +0.01% (p=0.000 n=18+18) Memmove/7-6 1.02GB/s ± 0% 1.02GB/s ± 1% ~ (p=0.139 n=19+20) Memmove/8-6 1.26GB/s ± 0% 1.26GB/s ± 0% +0.00% (p=0.000 n=18+18) Memmove/9-6 1.42GB/s ± 0% 1.42GB/s ± 0% +0.00% (p=0.000 n=17+18) Memmove/10-6 1.58GB/s ± 0% 1.58GB/s ± 0% +0.00% (p=0.000 n=19+19) Memmove/11-6 1.74GB/s ± 0% 1.74GB/s ± 0% +0.00% (p=0.001 n=18+17) Memmove/12-6 1.90GB/s ± 0% 1.90GB/s ± 0% +0.00% (p=0.000 n=19+19) Memmove/13-6 2.05GB/s ± 0% 2.05GB/s ± 0% +0.00% (p=0.000 n=18+19) Memmove/14-6 2.21GB/s ± 0% 2.21GB/s ± 0% +0.00% (p=0.000 n=16+20) Memmove/15-6 2.37GB/s ± 0% 2.37GB/s ± 0% +0.00% (p=0.004 n=19+20) Memmove/16-6 2.53GB/s ± 0% 2.53GB/s ± 0% +0.00% (p=0.000 n=16+16) Memmove/32-6 4.67GB/s ± 0% 4.67GB/s ± 0% +0.00% (p=0.000 n=17+17) Memmove/64-6 8.67GB/s ± 0% 8.64GB/s ± 0% -0.33% (p=0.000 n=18+17) Memmove/128-6 12.6GB/s ± 0% 11.6GB/s ± 0% -8.05% (p=0.000 n=16+19) Memmove/256-6 16.3GB/s ± 0% 16.6GB/s ± 0% +1.66% (p=0.000 n=20+18) Memmove/512-6 21.5GB/s ± 0% 24.4GB/s ± 0% +13.35% (p=0.000 n=18+17) Memmove/1024-6 24.7GB/s ± 0% 33.7GB/s ± 0% +36.12% (p=0.000 n=18+18) Memmove/2048-6 27.3GB/s ± 0% 43.3GB/s ± 0% +58.77% (p=0.000 n=19+17) Memmove/4096-6 37.5GB/s ± 0% 50.5GB/s ± 0% +34.56% (p=0.000 n=19+19) MemmoveUnalignedDst/1-6 135MB/s ± 0% 146MB/s ± 0% +7.69% (p=0.000 n=16+14) MemmoveUnalignedDst/2-6 271MB/s ± 0% 292MB/s ± 0% +7.69% (p=0.000 n=18+18) MemmoveUnalignedDst/3-6 438MB/s ± 0% 438MB/s ± 0% ~ (p=0.352 n=16+19) MemmoveUnalignedDst/4-6 584MB/s ± 0% 584MB/s ± 0% ~ (p=0.876 n=17+17) MemmoveUnalignedDst/5-6 631MB/s ± 1% 632MB/s ± 0% +0.25% (p=0.000 n=20+17) MemmoveUnalignedDst/6-6 759MB/s ± 0% 759MB/s ± 0% +0.00% (p=0.000 n=19+16) MemmoveUnalignedDst/7-6 885MB/s ± 0% 883MB/s ± 1% ~ (p=0.647 n=18+20) MemmoveUnalignedDst/8-6 1.08GB/s ± 0% 1.08GB/s ± 0% +0.00% (p=0.035 n=19+18) MemmoveUnalignedDst/9-6 1.22GB/s ± 0% 1.22GB/s ± 0% ~ (p=0.251 n=18+17) MemmoveUnalignedDst/10-6 1.35GB/s ± 0% 1.35GB/s ± 0% ~ (p=0.327 n=17+18) MemmoveUnalignedDst/11-6 1.49GB/s ± 0% 1.49GB/s ± 0% ~ (p=0.531 n=18+19) MemmoveUnalignedDst/12-6 1.63GB/s ± 0% 1.63GB/s ± 0% ~ (p=0.886 n=19+18) MemmoveUnalignedDst/13-6 1.76GB/s ± 0% 1.76GB/s ± 1% -0.24% (p=0.006 n=18+20) MemmoveUnalignedDst/14-6 1.90GB/s ± 0% 1.90GB/s ± 0% ~ (p=0.818 n=20+19) MemmoveUnalignedDst/15-6 2.03GB/s ± 0% 2.03GB/s ± 0% ~ (p=0.294 n=17+16) MemmoveUnalignedDst/16-6 2.17GB/s ± 0% 2.17GB/s ± 0% ~ (p=0.602 n=16+18) MemmoveUnalignedDst/32-6 4.05GB/s ± 0% 4.05GB/s ± 0% +0.00% (p=0.010 n=18+17) MemmoveUnalignedDst/64-6 7.59GB/s ± 0% 7.59GB/s ± 0% +0.00% (p=0.022 n=18+16) MemmoveUnalignedDst/128-6 11.1GB/s ± 0% 11.4GB/s ± 0% +2.79% (p=0.000 n=18+17) MemmoveUnalignedDst/256-6 16.4GB/s ± 0% 16.7GB/s ± 0% +1.59% (p=0.000 n=20+17) MemmoveUnalignedDst/512-6 15.7GB/s ± 0% 21.3GB/s ± 0% +35.87% (p=0.000 n=18+20) MemmoveUnalignedDst/1024-6 16.0GB/s ±20% 31.5GB/s ± 0% +96.93% (p=0.000 n=20+14) MemmoveUnalignedDst/2048-6 19.6GB/s ± 0% 42.1GB/s ± 0% +115.16% (p=0.000 n=17+18) MemmoveUnalignedDst/4096-6 6.41GB/s ± 0% 33.18GB/s ± 0% +417.56% (p=0.000 n=17+18) MemmoveUnalignedSrc/1-6 171MB/s ± 0% 166MB/s ± 0% -3.33% (p=0.000 n=19+16) MemmoveUnalignedSrc/2-6 343MB/s ± 0% 342MB/s ± 1% -0.41% (p=0.000 n=17+20) MemmoveUnalignedSrc/3-6 508MB/s ± 0% 493MB/s ± 1% -2.90% (p=0.000 n=17+17) MemmoveUnalignedSrc/4-6 677MB/s ± 0% 660MB/s ± 2% -2.55% (p=0.000 n=17+20) MemmoveUnalignedSrc/5-6 790MB/s ± 0% 790MB/s ± 0% ~ (p=0.139 n=17+17) MemmoveUnalignedSrc/6-6 948MB/s ± 0% 946MB/s ± 1% ~ (p=0.330 n=17+19) MemmoveUnalignedSrc/7-6 1.11GB/s ± 0% 1.11GB/s ± 0% -0.05% (p=0.026 n=17+17) MemmoveUnalignedSrc/8-6 1.38GB/s ± 0% 1.38GB/s ± 0% ~ (p=0.091 n=18+16) MemmoveUnalignedSrc/9-6 1.42GB/s ± 0% 1.40GB/s ± 1% -1.04% (p=0.000 n=19+20) MemmoveUnalignedSrc/10-6 1.58GB/s ± 0% 1.56GB/s ± 1% -1.15% (p=0.000 n=18+19) MemmoveUnalignedSrc/11-6 1.73GB/s ± 0% 1.71GB/s ± 1% -1.30% (p=0.000 n=20+20) MemmoveUnalignedSrc/12-6 1.89GB/s ± 0% 1.87GB/s ± 1% -1.18% (p=0.000 n=17+20) MemmoveUnalignedSrc/13-6 2.05GB/s ± 0% 2.02GB/s ± 1% -1.18% (p=0.000 n=17+20) MemmoveUnalignedSrc/14-6 2.21GB/s ± 0% 2.18GB/s ± 1% -1.14% (p=0.000 n=17+20) MemmoveUnalignedSrc/15-6 2.36GB/s ± 0% 2.34GB/s ± 1% -1.04% (p=0.000 n=17+20) MemmoveUnalignedSrc/16-6 2.52GB/s ± 0% 2.49GB/s ± 1% -1.26% (p=0.000 n=19+20) MemmoveUnalignedSrc/32-6 4.82GB/s ± 0% 4.61GB/s ± 0% -4.40% (p=0.000 n=19+20) MemmoveUnalignedSrc/64-6 5.03GB/s ± 4% 7.97GB/s ± 0% +58.55% (p=0.000 n=20+16) MemmoveUnalignedSrc/128-6 11.1GB/s ± 0% 11.2GB/s ± 0% +0.52% (p=0.000 n=17+18) MemmoveUnalignedSrc/256-6 16.5GB/s ± 0% 16.4GB/s ± 0% -0.10% (p=0.000 n=20+18) MemmoveUnalignedSrc/512-6 21.0GB/s ± 0% 22.1GB/s ± 0% +5.48% (p=0.000 n=14+17) MemmoveUnalignedSrc/1024-6 24.9GB/s ± 0% 31.9GB/s ± 0% +28.20% (p=0.000 n=19+20) MemmoveUnalignedSrc/2048-6 23.3GB/s ± 0% 33.8GB/s ± 0% +45.22% (p=0.000 n=17+19) MemmoveUnalignedSrc/4096-6 37.3GB/s ± 0% 42.7GB/s ± 0% +14.30% (p=0.000 n=17+17) Change-Id: Id66aa3e499ccfb117cb99d623ef326b50d057b64 Reviewed-on: https://go-review.googlesource.com/29590 Run-TryBot: Denis Nagorny <denis.nagorny@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Michael Munday authored
Adds the following instructions and uses them in the SSA backend: - ANDW - ORW - XORW The instruction encodings for 32-bit operations are typically shorter, particularly when an immediate is used. For example, XORW $-1, R1 only requires one instruction, whereas XOR requires two. Also removes some unused instructions (that were emulated): - ANDN - NAND - ORN - NOR Change-Id: Iff2a16f52004ba498720034e354be9771b10cac4 Reviewed-on: https://go-review.googlesource.com/30291Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Keith Randall authored
Better to just rematerialize them when needed instead of cross-register spilling or other techniques for keeping them in registers. This helps for amd64 code that does 1 << x. It is better to do loop: MOVQ $1, AX // materialize arg to SLLQ SLLQ CX, AX ... goto loop than to do MOVQ $1, AX // materialize outsize of loop loop: MOVQ AX, DX // save value that's about to be clobbered SLLQ CX, AX MOVQ DX, AX // move it back to the correct register goto loop Update #16092 Change-Id: If7ac290208f513061ebb0736e8a79dcb0ba338c0 Reviewed-on: https://go-review.googlesource.com/30471 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Ian Lance Taylor authored
The CgoExternalThreadSIGPROF test starts a thread at constructor time that does a busy loop. That can throw off some other tests. So only build that code if testprogcgo is built with the tag threadprof, and adjust the tests that use that code to pass that build tag. This revealed that the CgoPprofThread test was not testing what it should have, as it never actually started the cpuHog thread. It was passing because of the busy loop thread. Fix it to start the thread as intended. Change-Id: I087a9e4fc734a86be16a287456441afac5676beb Reviewed-on: https://go-review.googlesource.com/30362 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Larz Conwell authored
Currently if you declare a type overwriting a predeclared type and export methods on it they will be exposed in godoc, even though the type itself is not exported. This corrects that by making all methods on these types hidden, since that's the expected output. Fixes #9860 Change-Id: I14037bdcef1b4bbefcf299a143bac8bf363718e0 Reviewed-on: https://go-review.googlesource.com/20610Reviewed-by: Russ Cox <rsc@golang.org>
-
Jaana Burcu Dogan authored
It is pretty confusing when there are Go files ignored for mismatching build tags and similar and we output "no buildable Go files" without giving any other information about some Go files have been ignored. Fixes #17008. Change-Id: I1766ee86a9a7a72f6694deae3f73b47bfc9d0be5 Reviewed-on: https://go-review.googlesource.com/29113 Run-TryBot: Jaana Burcu Dogan <jbd@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 05 Oct, 2016 4 commits
-
-
Dmitriy Dudkin authored
Suppose you have already downloaded "foo.bar/baz", where the repo is for all of foo.bar/, and you then "go get -u foo.bar/...". The command-line wildcard expands to foo.bar/baz, and go get updates the foo.bar/ repo. Suppose that the repo update brought in foo.bar/quux, though, which depends on other.site/bar. Download does not consider foo.bar/quux, since it's only looking at foo.bar/baz, so it didn't download other.site/bar. After the download, we call importPaths(args) to decide what to install. That call was reevaluating the original wildcard with the new repo and matching foo.bar/quux, which was missing its dependency other.site/bar, causing a build failure. The fix in this CL is to remember the pre-download expansion of the argument list and pass it to the installer. Then only the things we tried to download get installed. The case where foo.bar/ is not even checked out yet continues to work, because in that case we leave the wildcard in place, and download reevaluates it during the download. The fix in this CL may not be the right long-term fix, but it is at least a fix. It may be that download should be passed all the original wildcards so that it can reexpand them as new code is downloaded, ideally reaching a fixed point. That can be left for another day. In short: - The problem is that the "install" half of "go get" was trying to install more than the "download" half was properly downloading. - The fix in this CL is to install just what was downloaded (install less). - It may be that a future CL should instead download what will be installed (download more). Fixes #14450. Change-Id: Ia1984761d24439549b7cff322bc0dbc262c1a653 Reviewed-on: https://go-review.googlesource.com/19892 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Lynn Boger authored
This updates runtime/memclr_ppc64x.s to improve performance, by unrolling loops for larger clears. Fixes #17348 benchmark old MB/s new MB/s speedup BenchmarkMemclr/5-80 199.71 406.63 2.04x BenchmarkMemclr/16-80 693.66 1817.41 2.62x BenchmarkMemclr/64-80 2309.35 5793.34 2.51x BenchmarkMemclr/256-80 5428.18 14765.81 2.72x BenchmarkMemclr/4096-80 8611.65 27191.94 3.16x BenchmarkMemclr/65536-80 8736.69 28604.23 3.27x BenchmarkMemclr/1M-80 9304.94 27600.09 2.97x BenchmarkMemclr/4M-80 8705.66 27589.64 3.17x BenchmarkMemclr/8M-80 8575.74 23631.04 2.76x BenchmarkMemclr/16M-80 8443.10 19240.68 2.28x BenchmarkMemclr/64M-80 8390.40 9493.04 1.13x BenchmarkGoMemclr/5-80 263.05 630.37 2.40x BenchmarkGoMemclr/16-80 904.33 1148.49 1.27x BenchmarkGoMemclr/64-80 2830.20 8756.70 3.09x BenchmarkGoMemclr/256-80 6064.59 20299.46 3.35x Change-Id: Ic76c9183c8b4129ba3df512ca8b0fe6bd424e088 Reviewed-on: https://go-review.googlesource.com/30373 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Munday <munday@ca.ibm.com> Reviewed-by: David Chase <drchase@google.com>
-
Quentin Smith authored
RHEL 7 introduces a new tool, update-ca-trust(8), which places the certificate bundle in a new location. Add this path to the list of locations that are searched for the certificate bundle. Fixes #15749 Change-Id: Idc97f885ee48ef085f1eb4dacbd1c2cf55f94ff5 Reviewed-on: https://go-review.googlesource.com/30375Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Fixes #13485. Change-Id: I11dd15c7d14fc19d42a3b48427a4cc1208b18e6a Reviewed-on: https://go-review.googlesource.com/30456Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-