- 06 Apr, 2017 13 commits
-
-
Josh Bleecher Snyder authored
The textual import/export format is ancient history. Change-Id: Iebe90bfd9bd3074eb191186d86e5f4286ce3b1f3 Reviewed-on: https://go-review.googlesource.com/39850 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
typenamesym is called from three places: typename, ngotype, and Type.Symbol. Only in typename do we actually need a Node. ngotype and Type.Symbol require only a Sym. And writing the newly created Node to Sym.Def is unsafe in a concurrent backend. Rather than use a mutex protect to Sym.Def, make typenamesym not touch Sym.Def. The assignment to Sym.Def was serving a second purpose, namely to prevent duplicate entries on signatlist. Preserve that functionality by switching signatlist to a map. This in turn requires that we sort signatlist when exporting it, to preserve reproducibility. We'd like to use Type.cmp for sorting, but that causes infinite recursion at the moment; see #19869. For now, use Type.LongString as the sort key, which is a complete description of the type. Type.LongString is relatively expensive, but we calculate it only once per type, and signatlist is generally fairly small, so the performance impact is minimal. Updates #15756 name old alloc/op new alloc/op delta Template 39.4MB ± 0% 39.4MB ± 0% ~ (p=0.222 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.151 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.095 n=5+5) SSA 1.25GB ± 0% 1.25GB ± 0% +0.04% (p=0.008 n=5+5) Flate 25.3MB ± 0% 25.4MB ± 0% ~ (p=0.056 n=5+5) GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.310 n=5+5) Reflect 78.3MB ± 0% 78.3MB ± 0% ~ (p=0.690 n=5+5) Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.548 n=5+5) XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.222 n=5+5) name old allocs/op new allocs/op delta Template 387k ± 0% 388k ± 0% ~ (p=0.056 n=5+5) Unicode 320k ± 0% 321k ± 0% +0.32% (p=0.032 n=5+5) GoTypes 1.14M ± 0% 1.15M ± 0% ~ (p=0.095 n=5+5) SSA 9.70M ± 0% 9.72M ± 0% +0.18% (p=0.008 n=5+5) Flate 234k ± 0% 235k ± 0% +0.60% (p=0.008 n=5+5) GoParser 317k ± 0% 317k ± 0% ~ (p=1.000 n=5+5) Reflect 982k ± 0% 983k ± 0% ~ (p=0.841 n=5+5) Tar 252k ± 1% 252k ± 0% ~ (p=0.310 n=5+5) XML 393k ± 0% 392k ± 0% ~ (p=0.548 n=5+5) Change-Id: I53a3b95d19cf1a7b7511a94fba896706addf84fb Reviewed-on: https://go-review.googlesource.com/39710 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Kale Blankenship authored
Updates #18437 Change-Id: Iaa8a35d18eca8be24763dd151ad9e324ecbf7f7b Reviewed-on: https://go-review.googlesource.com/34726 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
This is a straightforward refactoring, to reduce the scope of upcoming changes. The symbol size and AttrLocal=true was not set universally, but it appears not to matter, since toolstash -cmp is happy. Passes toolstash-check -all. Change-Id: I7f8392f939592d3a1bc6f61dec992f5661f42fca Reviewed-on: https://go-review.googlesource.com/39791 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
It was simply a wrapper around Link.Lookup. Unwrap everything. CL prepared using eg with template: package p import "cmd/internal/obj" func before(ctxt *obj.Link, name string, version int) *obj.LSym { return obj.Linklookup(ctxt, name, version) } func after(ctxt *obj.Link, name string, version int) *obj.LSym { return ctxt.Lookup(name, version) } Then one comment in cmd/asm/internal/asm/parse.go was manually updated (and gofmt'ed!), and func Linklookup deleted. Passes toolstash-check (as a sanity measure). Change-Id: Icc4d56b0b2b5c8888d3184c1898c48359ea1e638 Reviewed-on: https://go-review.googlesource.com/39715 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Daniel Martí authored
In particular, this lead to the code accepting invalid ETags as long as they finished with a '"'. Also remove a duplicate test case. Change-Id: Id59db3ebc4e4969562f891faef29111e77ee0e65 Reviewed-on: https://go-review.googlesource.com/39690 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Cherry Zhang authored
When a constant is both MOVCON (can fit into a MOV instruction) and BITCON (can fit into a logical instruction), the assembler chooses to use the MOVCON encoding, which is actually longer for logical instructions. We add MBCON rules explicitly to make sure it uses the BITCON encoding. Updates #19857. Change-Id: Ib9881be363cbc491ac2a0792b36b87e74eff34a8 Reviewed-on: https://go-review.googlesource.com/39652 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Cherry Zhang authored
For an AND that masks out leading or trailing bits, generic rules rewrite it to a pair of shifts. On ARM64, the mask actually can fit into an AND instruction. So we rewrite it back to AND. Fixes #19857. Change-Id: I479d7320ae4f29bb3f0056d5979bde4478063a8f Reviewed-on: https://go-review.googlesource.com/39651 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jeff Wendling authored
Plugin support is patchy at the moment, so disable the test for now until the test can be fixed. This way, we can get builders for ARMv5 running for the rest of the code. Updates #19674 Change-Id: I08aa211c08a85688656afe2ad2e680a2a6e5dfac Reviewed-on: https://go-review.googlesource.com/39716Reviewed-by:
-
Daniel Martí authored
This code was added recently, and it doesn't seem like the parameter will be useful in the near future. Change-Id: I5d64dadb6820c159b588262ab90df2461b5fdf04 Reviewed-on: https://go-review.googlesource.com/39692 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Josh Bleecher Snyder authored
The existing bulk/cached Prog allocator, Ctxt.NewProg, is not concurrency-safe. This CL moves Prog allocation to its clients, the compiler and the assembler. The assembler is so fast and generates so few Progs that it does not need optimization of Prog allocation. I could not generate measureable changes. And even if I could, the assembly is a miniscule portion of build times. The compiler already has a natural place to manage Prog allocation; this CL migrates the Prog cache there. It will be made concurrency-safe in a later CL by partitioning the Prog cache into chunks and assigning each chunk to a different goroutine to manage. This CL does cause a performance degradation when the compiler is invoked with the -S flag (to dump assembly). However, such usage is rare and almost always done manually. The one instance I know of in a test is TestAssembly in cmd/compile/internal/gc, and I did not detect a measurable performance impact there. Passes toolstash-check -all. Minor compiler performance impact. Updates #15756 Performance impact from just this CL: name old time/op new time/op delta Template 213ms ± 4% 213ms ± 4% ~ (p=0.571 n=49+49) Unicode 89.1ms ± 3% 89.4ms ± 3% ~ (p=0.388 n=47+48) GoTypes 581ms ± 2% 584ms ± 3% +0.56% (p=0.019 n=47+48) SSA 6.48s ± 2% 6.53s ± 2% +0.84% (p=0.000 n=47+49) Flate 128ms ± 4% 128ms ± 4% ~ (p=0.832 n=49+49) GoParser 152ms ± 3% 152ms ± 3% ~ (p=0.815 n=48+47) Reflect 371ms ± 4% 371ms ± 3% ~ (p=0.617 n=50+47) Tar 112ms ± 4% 112ms ± 3% ~ (p=0.724 n=49+49) XML 208ms ± 3% 208ms ± 4% ~ (p=0.678 n=49+50) [Geo mean] 284ms 285ms +0.18% name old user-ns/op new user-ns/op delta Template 251M ± 7% 252M ±11% ~ (p=0.704 n=49+50) Unicode 107M ± 7% 108M ± 5% +1.25% (p=0.036 n=50+49) GoTypes 738M ± 3% 740M ± 3% ~ (p=0.305 n=49+48) SSA 8.83G ± 2% 8.86G ± 4% ~ (p=0.098 n=47+50) Flate 146M ± 6% 147M ± 3% ~ (p=0.584 n=48+41) GoParser 178M ± 6% 179M ± 5% +0.93% (p=0.036 n=49+48) Reflect 441M ± 4% 446M ± 7% ~ (p=0.218 n=44+49) Tar 126M ± 5% 126M ± 5% ~ (p=0.766 n=48+49) XML 245M ± 5% 244M ± 4% ~ (p=0.359 n=50+50) [Geo mean] 341M 342M +0.51% Performance impact from this CL combined with its parent: name old time/op new time/op delta Template 213ms ± 3% 214ms ± 4% ~ (p=0.685 n=47+50) Unicode 89.8ms ± 6% 90.5ms ± 6% ~ (p=0.055 n=50+50) GoTypes 584ms ± 3% 585ms ± 2% ~ (p=0.710 n=49+47) SSA 6.50s ± 2% 6.53s ± 2% +0.39% (p=0.011 n=46+50) Flate 128ms ± 3% 128ms ± 4% ~ (p=0.855 n=47+49) GoParser 152ms ± 3% 152ms ± 3% ~ (p=0.666 n=49+49) Reflect 371ms ± 3% 372ms ± 3% ~ (p=0.298 n=48+48) Tar 112ms ± 5% 113ms ± 3% ~ (p=0.107 n=49+49) XML 208ms ± 3% 208ms ± 2% ~ (p=0.881 n=50+49) [Geo mean] 285ms 285ms +0.26% name old user-ns/op new user-ns/op delta Template 254M ± 9% 252M ± 8% ~ (p=0.290 n=49+50) Unicode 106M ± 6% 108M ± 7% +1.44% (p=0.034 n=50+50) GoTypes 741M ± 4% 743M ± 4% ~ (p=0.992 n=50+49) SSA 8.86G ± 2% 8.83G ± 3% ~ (p=0.158 n=47+49) Flate 147M ± 4% 148M ± 5% ~ (p=0.832 n=50+49) GoParser 179M ± 5% 178M ± 5% ~ (p=0.370 n=48+50) Reflect 441M ± 6% 445M ± 7% ~ (p=0.246 n=45+47) Tar 126M ± 6% 126M ± 6% ~ (p=0.815 n=49+50) XML 244M ± 3% 245M ± 4% ~ (p=0.190 n=50+50) [Geo mean] 342M 342M +0.17% Change-Id: I020f1c079d495fbe2e15ccb51e1ea2cc1b5a1855 Reviewed-on: https://go-review.googlesource.com/39634 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Change-Id: I2c402d9491b373316775b515ce389555e58acb1a Reviewed-on: https://go-review.googlesource.com/39636 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
The existing bulk Prog allocator is not concurrency-safe. To allow for concurrency-safe bulk allocation of Progs, I want to move Prog allocation and caching upstream, to the clients of cmd/internal/obj. This is a preliminary enabling refactoring. After this CL, instead of calling Ctxt.NewProg throughout the assemblers, we thread through a newprog function that returns a new Prog. That function is set up to be Ctxt.NewProg, so there are no real changes in this CL; this CL only establishes the plumbing. Passes toolstash-check -all. Negligible compiler performance impact. Updates #15756 name old time/op new time/op delta Template 213ms ± 3% 214ms ± 4% ~ (p=0.574 n=49+47) Unicode 90.1ms ± 5% 89.9ms ± 4% ~ (p=0.417 n=50+49) GoTypes 585ms ± 4% 584ms ± 3% ~ (p=0.466 n=49+49) SSA 6.50s ± 3% 6.52s ± 2% ~ (p=0.251 n=49+49) Flate 128ms ± 4% 128ms ± 4% ~ (p=0.673 n=49+50) GoParser 152ms ± 3% 152ms ± 3% ~ (p=0.810 n=48+49) Reflect 372ms ± 4% 372ms ± 5% ~ (p=0.778 n=49+50) Tar 113ms ± 5% 111ms ± 4% -0.98% (p=0.016 n=50+49) XML 208ms ± 3% 208ms ± 2% ~ (p=0.483 n=47+49) [Geo mean] 285ms 285ms -0.17% name old user-ns/op new user-ns/op delta Template 253M ± 8% 254M ± 9% ~ (p=0.899 n=50+50) Unicode 106M ± 9% 106M ±11% ~ (p=0.642 n=50+50) GoTypes 736M ± 4% 740M ± 4% ~ (p=0.121 n=50+49) SSA 8.82G ± 3% 8.88G ± 2% +0.65% (p=0.006 n=49+48) Flate 147M ± 4% 147M ± 5% ~ (p=0.844 n=47+48) GoParser 179M ± 4% 178M ± 6% ~ (p=0.785 n=50+50) Reflect 443M ± 6% 441M ± 5% ~ (p=0.850 n=48+47) Tar 126M ± 5% 126M ± 5% ~ (p=0.734 n=50+50) XML 244M ± 5% 244M ± 5% ~ (p=0.594 n=49+50) [Geo mean] 341M 341M +0.11% Change-Id: Ice962f61eb3a524c2db00a166cb582c22caa7d68 Reviewed-on: https://go-review.googlesource.com/39633 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 05 Apr, 2017 10 commits
-
-
Josh Bleecher Snyder authored
Updates #15756 Updates #19822 Change-Id: I98b17dcbbfd80e7e164b0523185382175fe2d89b Reviewed-on: https://go-review.googlesource.com/39554 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Austin Clements authored
Stack spans don't internally use many of the fields of the mspan, which means things like the size class and element size get left over from whatever last used the mspan. This can lead to confusing crashes and debugging. Zero these fields or initialize them to something reasonable. This also lets us simplify some code that currently has to distinguish between heap and stack spans. Change-Id: I9bd114e76c147bb32de497045b932f8bf1988bbf Reviewed-on: https://go-review.googlesource.com/38573 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #19276. Change-Id: I64f8f80331d09956b6698c0b004ed7f7d70857fc Reviewed-on: https://go-review.googlesource.com/39591 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Russ Cox authored
This was fixed in CL 37598 but the test was (rightly) dropped because it modified $GOROOT. Here's a variant that does not. For #19151. Change-Id: Iccdbbf9ae8ac4c252e52f4f8ff996963573c4682 Reviewed-on: https://go-review.googlesource.com/39592 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Commit 44ed88a5 moved printing of the "sweep done" gcpacertrace message so that it is printed when the final sweeper finishes. However, by this point some other thread has often already observed that there are no more spans to sweep and zeroed sweepPagesPerByte. Avoid printing a 0 sweep ratio in the trace when this race happens by getting the value of the sweep ratio upon entry to sweepone and printing that. Change-Id: Iac0c48ae899e12f193267cdfb012c921f8b71c85 Reviewed-on: https://go-review.googlesource.com/39492 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: Iaeb7bcbcdbc46c0e0e40b0aa070c706e0ca53013 Reviewed-on: https://go-review.googlesource.com/39555 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Lynn Boger authored
The comments in this package state that users should be migrating code that uses the syscall package to its corresponding package in x/sys. However, the syscall.Signal and syscall.Errno types and the syscall.SysProcAttr struct is not defined in the x/sys package and still need to be referenced from within syscall. This adds a change to the comments to clarify that the migration will need to continue to use some references to syscall for now. Fixes #19560 Change-Id: I8abb96b93bea90070ce461da16dc7bcf7b4b29c1 Reviewed-on: https://go-review.googlesource.com/39450Reviewed-by:
Rob Pike <r@golang.org>
-
Russ Cox authored
Followup to CL 39152. Change-Id: I9bfed0c6071ea3d3a43294a6c4a50edc131368cf Reviewed-on: https://go-review.googlesource.com/39313 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Lorenzo Masini authored
Added -S flag to print go source file line above corresponding disassembly: $ go tool objdump -S -s main.main fmthello TEXT main.main(SB) /home/rugginoso/Documents/src/go/src/cmd/objdump/testdata/fmthello.go func main() { 0x47d450 64488b0c25f8ffffff FS MOVQ FS:0xfffffff8, CX 0x47d459 483b6110 CMPQ 0x10(CX), SP 0x47d45d 7631 JBE 0x47d490 0x47d45f 4883ec18 SUBQ $0x18, SP 0x47d463 48896c2410 MOVQ BP, 0x10(SP) 0x47d468 488d6c2410 LEAQ 0x10(SP), BP Println("hello, world") 0x47d46d 488d0563b00200 LEAQ 0x2b063(IP), AX 0x47d474 48890424 MOVQ AX, 0(SP) 0x47d478 48c74424080c000000 MOVQ $0xc, 0x8(SP) 0x47d481 e81a000000 CALL main.Println(SB) } 0x47d486 488b6c2410 MOVQ 0x10(SP), BP 0x47d48b 4883c418 ADDQ $0x18, SP 0x47d48f c3 RET func main() { 0x47d490 e8ebf1fcff CALL runtime.morestack_noctxt(SB) 0x47d495 ebb9 JMP main.main(SB) Execution time: $ time go tool objdump testdata/fmthello > /dev/null real 0m0.430s user 0m0.440s sys 0m0.000s $ time go tool objdump -S testdata/fmthello > /dev/null real 0m0.471s user 0m0.476s sys 0m0.012s Fixes #18245 Change-Id: I9b2f8338f9ee443c1352efd270d3ba85e3dd9b78 Reviewed-on: https://go-review.googlesource.com/37953 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Alex Brainman authored
For #17540. Change-Id: Ie01f39797526934fa553f4279cbde6c7cbf14154 Reviewed-on: https://go-review.googlesource.com/36854Reviewed-by:
-
- 04 Apr, 2017 6 commits
-
-
Josh Bleecher Snyder authored
This is a holdover from the days when we did not have full SSA coverage and compiled things optimistically, and catching the panic obscures useful information. Change-Id: I196790cb6b97419d92b318a2dfa7f1e1097cefb7 Reviewed-on: https://go-review.googlesource.com/39534 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
CL 38801 introduced automatic commutative rule generation. Manual order canonicalization rules thus lead to infinite loops. Fixes #19842 Change-Id: I877c476152f4d207fdc67bc6f3018265aa9bc5ac Reviewed-on: https://go-review.googlesource.com/39533 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filip Gruszczyński authored
Providing size hint when creating a map allows avoiding re-allocating underlying data structure if we know how many elements are going to be inserted. This can be used for example during decoding maps in gob. Fixes #19599 Change-Id: I108035fec29391215d2261a73eaed1310b46bab1 Reviewed-on: https://go-review.googlesource.com/38335Reviewed-by:
-
Rob Pike authored
This was a subtle bug introduced in the previous release's fix for issue 16156. The definition of empty template was broken, causing the answer to depend on the order of templates in the map. Fixes #16156 (for real). Fixes #19294. Fixes #19204. Change-Id: I1cd915c94534cad3116d83bd158cbc28700510b9 Reviewed-on: https://go-review.googlesource.com/38420 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
- use a string lookup to detect if a single byte is a space character - determine the exact number of fields for ASCII and a possibly underestimated number of fields for non ASCII strings by doing a separate byte for byte scan of the input string before collecting the fields in an extra pass - provide a fast path for ASCII only strings when collecting the fields - avoid utf8.DecodeRuneInString and unicode.IsSpace for ASCII characters Used golang.org/cl/33108 from Joe Tsai as starting point. name old time/op new time/op delta Fields/ASCII/16 284ns ± 1% 116ns ± 2% -59.30% (p=0.000 n=9+10) Fields/ASCII/256 3.81µs ± 1% 0.80µs ± 1% -79.10% (p=0.000 n=10+10) Fields/ASCII/4096 61.4µs ± 1% 12.3µs ± 1% -79.96% (p=0.000 n=10+9) Fields/ASCII/65536 982µs ± 1% 235µs ± 0% -76.04% (p=0.000 n=10+9) Fields/ASCII/1048576 16.7ms ± 2% 5.4ms ± 1% -67.52% (p=0.000 n=10+10) Fields/Mixed/16 314ns ± 1% 168ns ± 1% -46.33% (p=0.000 n=9+10) Fields/Mixed/256 3.92µs ± 1% 1.17µs ± 1% -70.19% (p=0.000 n=10+10) Fields/Mixed/4096 69.1µs ± 1% 19.0µs ± 1% -72.53% (p=0.000 n=10+10) Fields/Mixed/65536 1.12ms ± 1% 0.39ms ± 0% -65.37% (p=0.000 n=10+9) Fields/Mixed/1048576 19.0ms ± 2% 7.3ms ± 4% -61.75% (p=0.000 n=10+9) name old speed new speed delta Fields/ASCII/16 56.3MB/s ± 1% 138.1MB/s ± 2% +145.31% (p=0.000 n=9+10) Fields/ASCII/256 67.1MB/s ± 1% 321.0MB/s ± 1% +378.26% (p=0.000 n=10+10) Fields/ASCII/4096 66.7MB/s ± 1% 333.0MB/s ± 1% +398.97% (p=0.000 n=10+9) Fields/ASCII/65536 66.7MB/s ± 1% 278.4MB/s ± 0% +317.39% (p=0.000 n=10+9) Fields/ASCII/1048576 62.7MB/s ± 2% 192.9MB/s ± 1% +207.82% (p=0.000 n=10+10) Fields/Mixed/16 51.0MB/s ± 2% 94.9MB/s ± 1% +85.87% (p=0.000 n=10+10) Fields/Mixed/256 65.4MB/s ± 1% 219.2MB/s ± 1% +235.33% (p=0.000 n=10+10) Fields/Mixed/4096 59.3MB/s ± 1% 215.7MB/s ± 1% +263.98% (p=0.000 n=10+10) Fields/Mixed/65536 58.6MB/s ± 1% 169.1MB/s ± 0% +188.73% (p=0.000 n=10+9) Fields/Mixed/1048576 55.1MB/s ± 2% 144.0MB/s ± 4% +161.44% (p=0.000 n=10+9) Updates #19789 Updates #17856 Change-Id: If2ce1479542702e9cd65a82a462ba55ac8eb3876 Reviewed-on: https://go-review.googlesource.com/37959 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Keith Randall authored
Popcount instructions on amd64 are not guaranteed to be present, so we must guard their call. Rewrite rules can't generate control flow at the moment, so the intrinsifier needs to generate that code. name old time/op new time/op delta OnesCount-8 2.47ns ± 5% 1.04ns ± 2% -57.70% (p=0.000 n=10+10) OnesCount16-8 1.05ns ± 1% 0.78ns ± 0% -25.56% (p=0.000 n=9+8) OnesCount32-8 1.63ns ± 5% 1.04ns ± 2% -35.96% (p=0.000 n=10+10) OnesCount64-8 2.45ns ± 0% 1.04ns ± 1% -57.55% (p=0.000 n=6+10) Update #18616 Change-Id: I4aff2cc9aa93787898d7b22055fe272a7cf95673 Reviewed-on: https://go-review.googlesource.com/38320 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 03 Apr, 2017 11 commits
-
-
Eric Lagergren authored
The recently updated Count functions declare variables before special-cased returns. Change-Id: I8f726118336b7b0ff72117d12adc48b6e37e60ea Reviewed-on: https://go-review.googlesource.com/39357Reviewed-by:
-
Josh Bleecher Snyder authored
This provides better diagnostics when it occurs. Updates #19751 Change-Id: I87db54c22e1345891b418c1741dc76ac5fb8ed00 Reviewed-on: https://go-review.googlesource.com/39358 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Eric Lagergren authored
Change-Id: I1f1cfb161640eb8756fb1a283892d06b30b7a8fa Reviewed-on: https://go-review.googlesource.com/39356Reviewed-by:
-
Josh Bleecher Snyder authored
When a map is small, it's not worth putting the contents in an array and then looping over the array. Just generate code instead. This makes smaller binaries. It might also be better for cache lines. It also can avoids adding control flow in the middle of the init function, which can be very large. Eliminating this source of extra blocks makes phi insertion easier for temp-heavy init functions. This reduces the time required for compiler to panic while compiling the code in #19751 from 15 minutes to 45 seconds. The cutoff of 25 was chosen fairly unscientifically by looking at the size of cmd/go. Cutoff of 0: 10689604 Cutoff of 5: 10683572 Cutoff of 15: 10682324 Cutoff of 25: 10681700 Cutoff of 50: 10685476 Cutoff of 100: 10689412 There are probably more sophisticated mechanisms available. For example, the smaller the key/value sizes, the better generated code will be vs a table. Nevertheless this is simple and seems like a good start. Updates #19751 name old time/op new time/op delta Template 204ms ± 6% 202ms ± 5% -0.78% (p=0.027 n=47+45) Unicode 84.8ms ± 6% 85.2ms ± 7% ~ (p=0.146 n=46+45) GoTypes 551ms ± 2% 556ms ± 3% +0.76% (p=0.004 n=43+45) SSA 3.93s ± 3% 3.95s ± 4% ~ (p=0.179 n=50+49) Flate 123ms ± 4% 123ms ± 5% ~ (p=0.201 n=47+49) GoParser 145ms ± 3% 145ms ± 4% ~ (p=0.937 n=50+50) Reflect 356ms ± 3% 354ms ± 5% -0.44% (p=0.048 n=46+50) Tar 107ms ± 6% 106ms ± 6% ~ (p=0.188 n=50+49) XML 201ms ± 4% 200ms ± 4% ~ (p=0.085 n=50+49) name old user-ns/op new user-ns/op delta Template 252M ± 9% 250M ± 7% ~ (p=0.206 n=49+47) Unicode 106M ± 7% 106M ± 9% ~ (p=0.331 n=47+46) GoTypes 724M ± 5% 729M ± 5% ~ (p=0.160 n=47+49) SSA 5.64G ± 2% 5.62G ± 4% ~ (p=0.148 n=47+50) Flate 147M ± 6% 147M ± 5% ~ (p=0.466 n=50+49) GoParser 179M ± 5% 179M ± 6% ~ (p=0.584 n=50+49) Reflect 448M ± 6% 441M ± 8% -1.39% (p=0.027 n=50+49) Tar 124M ± 6% 123M ± 5% ~ (p=0.221 n=50+47) XML 244M ± 5% 243M ± 4% ~ (p=0.275 n=49+49) name old alloc/op new alloc/op delta Template 39.9MB ± 0% 39.4MB ± 0% -1.28% (p=0.008 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.310 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.421 n=5+5) SSA 854MB ± 0% 854MB ± 0% ~ (p=0.151 n=5+5) Flate 25.3MB ± 0% 25.3MB ± 0% ~ (p=1.000 n=5+5) GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.222 n=5+5) Reflect 78.2MB ± 0% 78.2MB ± 0% ~ (p=1.000 n=5+5) Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.841 n=5+5) XML 42.3MB ± 0% 42.3MB ± 0% -0.15% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 390k ± 1% 386k ± 1% -1.05% (p=0.016 n=5+5) Unicode 319k ± 0% 320k ± 0% ~ (p=0.310 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.421 n=5+5) SSA 7.60M ± 0% 7.59M ± 0% ~ (p=0.310 n=5+5) Flate 234k ± 0% 235k ± 1% ~ (p=1.000 n=5+5) GoParser 315k ± 1% 317k ± 0% ~ (p=0.151 n=5+5) Reflect 978k ± 0% 978k ± 0% ~ (p=0.841 n=5+5) Tar 251k ± 1% 251k ± 1% ~ (p=0.690 n=5+5) XML 394k ± 0% 392k ± 0% ~ (p=0.056 n=5+5) Change-Id: Ic53a18627082abe075a1cbc33330ce015e50850a Reviewed-on: https://go-review.googlesource.com/39354 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Note that this is a redo of an undo of the original buggy CL 38666. We have lots of rewrite rules that vary only in the fact that we have 2 versions for the 2 different orderings of various commuting ops. For example: (ADDL x (MOVLconst [c])) -> (ADDLconst [c] x) (ADDL (MOVLconst [c]) x) -> (ADDLconst [c] x) It can get unwieldly quickly, especially when there is more than one commuting op in a rule. Our existing "fix" for this problem is to have rules that canonicalize the operations first. For example: (Eq64 x (Const64 <t> [c])) && x.Op != OpConst64 -> (Eq64 (Const64 <t> [c]) x) Subsequent rules can then assume if there is a constant arg to Eq64, it will be the first one. This fix kinda works, but it is fragile and only works when we remember to include the required extra rules. The fundamental problem is that the rule matcher doesn't know anything about commuting ops. This CL fixes that fact. We already have information about which ops commute. (The register allocator takes advantage of commutivity.) The rule generator now automatically generates multiple rules for a single source rule when there are commutative ops in the rule. We can now drop all of our almost-duplicate source-level rules and the canonicalization rules. I have some CLs in progress that will be a lot less verbose when the rule generator handles commutivity for me. I had to reorganize the load-combining rules a bit. The 8-way OR rules generated 128 different reorderings, which was causing the generator to put too much code in the rewrite*.go files (the big ones were going from 25K lines to 132K lines). Instead I reorganized the rules to combine pairs of loads at a time. The generated rule files are now actually a bit (5%) smaller. Make.bash times are ~unchanged. Compiler benchmarks are not observably different. Probably because we don't spend much compiler time in rule matching anyway. I've also done a pass over all of our ops adding commutative markings for ops which hadn't had them previously. Fixes #18292 Change-Id: Ic1c0e43fbf579539f459971625f69690c9ab8805 Reviewed-on: https://go-review.googlesource.com/38801 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
x*2 -> x+x x/c, c power of 2 -> x*(1/c) Fixes #19827 Change-Id: I74c9f0b5b49b2ed26c0990314c7d1d5f9631b6f1 Reviewed-on: https://go-review.googlesource.com/39295 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Instead of walking the list of nodes twice, once to find static entries to add to an array and once to find dynamic entries to generate code for, do the split once up front, into two slices. Then process each slice individually. This makes the code easier to read and more importantly, easier to modify. While we're here, add a TODO to avoid using temporaries for mapassign_fast calls. It's not an important TODO; the generated code would be basically identical. It would just avoid a minor amount of pointless SSA optimization work. Passes toolstash-check. No measureable compiler performance impact. Updates #19751 Change-Id: I84a8f2c22f9025c718ef34639059d7bd02a3c406 Reviewed-on: https://go-review.googlesource.com/39351 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Russ Cox authored
Fixes #19829. Change-Id: I8500fd73c37b504d6ea25f5aff7017fbc0718570 Reviewed-on: https://go-review.googlesource.com/39314 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates #13560 Change-Id: I9bc08ca5cf0627e653d55f748ebb83be8b69ea3b Reviewed-on: https://go-review.googlesource.com/39296 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This triggers 119 times during make.bash. This CL reduces the time it takes for the compiler to panic while compiling the code in #19751 from 22 minutes to 15 minutes. Yay, I guess. Updates #19751 Change-Id: I8ca7f1ae75f89d1eb2a361d67b3055a975221734 Reviewed-on: https://go-review.googlesource.com/39294 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Chase authored
Old buggy hardware incorrectly executes the shift-left-K then shift-right-K idiom for clearing K leftmost bits. Use a right rotate instead of shift to avoid triggering the bug. Fixes #19809. Change-Id: I6dc646b183c29e9d01aef944729f34388dcc687d Reviewed-on: https://go-review.googlesource.com/39310 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
