- 29 Mar, 2017 16 commits
-
-
Keith Randall authored
This reverts commit 041ecb69. Reason for revert: Not working on S390x and some 386 archs. I have a guess why the S390x is failing. No clue on the 386 yet. Revert until I can figure it out. Change-Id: I64f1ce78fa6d1037ebe7ee2a8a8107cb4c1db70c Reviewed-on: https://go-review.googlesource.com/38790Reviewed-by:
Keith Randall <khr@golang.org>
-
Russ Cox authored
Change-Id: I25db1d637dd461cec67ba70659d523b46895c113 Reviewed-on: https://go-review.googlesource.com/38744Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Russ Cox authored
rsc.io/toolstash is gone; use rsc.io/pprof_mac_fix. This fixes a bug in the test. It turns out the code being tested here is also broken, so the test still doesn't pass after this CL (filed #19769). Change-Id: Ieb725c321d7fab600708e133ae28f531e55521ad Reviewed-on: https://go-review.googlesource.com/38743Reviewed-by:
-
David Chase authored
The uintptr-typed Data field in reflect.SliceHeader and reflect.StringHeader needs special treatment because it is really a pointer. Add the special treatment in walk for bug #19168 to escape analysis. Includes extra debugging that was helpful. Fixes #19743. Change-Id: I6dab5002f0d436c3b2a7cdc0156e4fc48a43d6fe Reviewed-on: https://go-review.googlesource.com/38738 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
David Lazar authored
Previously, an inlined call to wg.Done() in package main would have the following incorrect symbol name: main.(*sync.WaitGroup).Done This change modifies methodname to return the correct symbol name: sync.(*WaitGroup).Done This fix was suggested by @mdempsky. Fixes #19467. Change-Id: I0117838679ac5353789299c618ff8c326712d94d Reviewed-on: https://go-review.googlesource.com/37866Reviewed-by:Austin Clements <austin@google.com>
-
David Lazar authored
Change-Id: If1a3396175f2afa607d56efd1444181334a9ae3e Reviewed-on: https://go-review.googlesource.com/37862Reviewed-by:
-
David Lazar authored
The `skip` argument passed to runtime.Caller and runtime.Callers should be interpreted as the number of logical calls to skip (rather than the number of physical stack frames to skip). This changes runtime.Callers to skip inlined calls in addition to physical stack frames. The result value of runtime.Callers is a slice of program counters ([]uintptr) representing physical stack frames. If the `skip` parameter to runtime.Callers skips part-way into a physical frame, there is no convenient way to encode that in the resulting slice. To avoid changing the API in an incompatible way, our solution is to store the number of skipped logical calls of the first frame in the _second_ uintptr returned by runtime.Callers. Since this number is a small integer, we encode it as a valid PC value into a small symbol called: runtime.skipPleaseUseCallersFrames For example, if f() calls g(), g() calls `runtime.Callers(2, pcs)`, and g() is inlined into f, then the frame for f will be partially skipped, resulting in the following slice: pcs = []uintptr{pc_in_f, runtime.skipPleaseUseCallersFrames+1, ...} We store the skip PC in pcs[1] instead of pcs[0] so that `pcs[i:]` will truncate the captured stack trace rather than grow it for all i. Updates #19348. Change-Id: I1c56f89ac48c29e6f52a5d085567c6d77d499cf1 Reviewed-on: https://go-review.googlesource.com/37854 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
David Lazar authored
Previously, we could not run tests with -l=4 on NaCl since the buildrun action is not supported on NaCl. This lets us run tests with build flags on NaCl. Change-Id: I103370c7b823b4ff46f47df97e802da0dc2bc7c3 Reviewed-on: https://go-review.googlesource.com/38170 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #19753. Change-Id: Ib20a69b1d0bcc42aa9e924918bcb578d6a560a31 Reviewed-on: https://go-review.googlesource.com/38742 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
The aLongTimeAgo time value in net and net/http is used to cancel in-flight read and writes. It was set to time.Unix(233431200, 0) which seemed like far enough in the past. But Raspberry Pis, lacking a real time clock, had to spoil the fun and boot in 1970 at the Unix epoch time, breaking assumptions in net and net/http. So change aLongTimeAgo to time.Unix(1, 0), which seems like the earliest safe value. I don't trust subsecond values on all operating systems, and I don't trust the Unix zero time. The Raspberry Pis do advance their clock at least. And the reported problem was that Hijack on a ResponseWriter hung forever, waiting for the connection read operation to finish. So now, even if kernel + userspace boots in under a second (unlikely), the Hijack will just have to wait for up to a second. Fixes #19747 Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a Reviewed-on: https://go-review.googlesource.com/38785 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Keith Randall authored
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. [Note to reviewers: check these carefully. Most of the other rule changes are trivial.] 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: I999b1307272e91965b66754576019dedcbe7527a Reviewed-on: https://go-review.googlesource.com/38666 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Austin Clements authored
reflect.callReflect heap-allocates a stack frame and then constructs pointers to the arguments and result areas of that frame. However, if there are no results, the results pointer will point past the end of the frame allocation. If there are also no arguments, the arguments pointer will also point past the end of the frame allocation. If the GC observes either these pointers, it may panic. Fix this by not constructing these pointers if these areas of the frame are empty. This adds a test of calling no-argument/no-result methods via reflect, since nothing in std did this before. However, it's quite difficult to demonstrate the actual failure because it depends on both exact allocation patterns and on GC scanning the goroutine's stack while inside one of the typedmemmovepartial calls. I also audited other uses of typedmemmovepartial and memclrNoHeapPointers in reflect, since these are the most susceptible to this. These appear to be the only two cases that can construct out-of-bounds arguments to these functions. Fixes #19724. Change-Id: I4b83c596b5625dc4ad0567b1e281bad4faef972b Reviewed-on: https://go-review.googlesource.com/38736 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Rick Hudson authored
Currently for spans with up to 1 MBytes (128 pages) we maintain an array indexed by the number of pages in the span. This is efficient both in terms of space as well as time to insert or remove a span of a particular size. Unfortunately for spans larger than 1 MByte we currently place them on a separate linked list. This results in O(n) behavior. Now that we are seeing heaps approaching 100 GBytes n is large enough to be noticed in real programs. This change replaces the linked list now used with a balanced binary tree structure called a treap. A treap is a probabilistically balanced tree offering O(logN) behavior for inserting and removing spans. To verify that this approach will work we start with noting that only spans with sizes > 1MByte will be put into the treap. This means that to support 1 TByte a treap will need at most 1 million nodes and can ideally be held in a treap with a depth of 20. Experiments with adding and removing randomly sized spans from the treap seem to result in treaps with depths of about twice the ideal or 40. A petabyte would require a tree of only twice again that depth again so this algorithm should last well into the future. Fixes #19393 Go1 benchmarks indicate this is basically an overall wash. Tue Mar 28 21:29:21 EDT 2017 name old time/op new time/op delta BinaryTree17-4 2.42s ± 1% 2.42s ± 1% ~ (p=0.980 n=21+21) Fannkuch11-4 3.00s ± 1% 3.18s ± 4% +6.10% (p=0.000 n=22+24) FmtFprintfEmpty-4 40.5ns ± 1% 40.3ns ± 3% ~ (p=0.692 n=22+25) FmtFprintfString-4 65.9ns ± 3% 64.6ns ± 1% -1.98% (p=0.000 n=24+23) FmtFprintfInt-4 69.6ns ± 1% 68.0ns ± 7% -2.30% (p=0.001 n=21+22) FmtFprintfIntInt-4 102ns ± 2% 99ns ± 1% -3.07% (p=0.000 n=23+23) FmtFprintfPrefixedInt-4 126ns ± 0% 125ns ± 0% -0.79% (p=0.000 n=19+17) FmtFprintfFloat-4 206ns ± 2% 205ns ± 1% ~ (p=0.671 n=23+21) FmtManyArgs-4 441ns ± 1% 445ns ± 1% +0.88% (p=0.000 n=22+23) GobDecode-4 5.73ms ± 1% 5.86ms ± 1% +2.37% (p=0.000 n=23+22) GobEncode-4 4.51ms ± 1% 4.89ms ± 1% +8.32% (p=0.000 n=22+22) Gzip-4 197ms ± 0% 202ms ± 1% +2.75% (p=0.000 n=23+24) Gunzip-4 32.9ms ± 8% 32.7ms ± 2% ~ (p=0.466 n=23+24) HTTPClientServer-4 57.3µs ± 1% 56.7µs ± 1% -0.94% (p=0.000 n=21+22) JSONEncode-4 13.8ms ± 1% 13.9ms ± 2% +1.14% (p=0.000 n=22+23) JSONDecode-4 47.4ms ± 1% 48.1ms ± 1% +1.49% (p=0.000 n=23+23) Mandelbrot200-4 3.92ms ± 0% 3.92ms ± 1% +0.21% (p=0.000 n=22+22) GoParse-4 2.89ms ± 1% 2.87ms ± 1% -0.68% (p=0.000 n=21+22) RegexpMatchEasy0_32-4 73.6ns ± 1% 72.0ns ± 2% -2.15% (p=0.000 n=21+22) RegexpMatchEasy0_1K-4 173ns ± 1% 173ns ± 1% ~ (p=0.847 n=22+24) RegexpMatchEasy1_32-4 71.9ns ± 1% 69.8ns ± 1% -2.99% (p=0.000 n=23+20) RegexpMatchEasy1_1K-4 314ns ± 1% 308ns ± 1% -1.91% (p=0.000 n=22+23) RegexpMatchMedium_32-4 106ns ± 0% 105ns ± 1% -0.58% (p=0.000 n=19+21) RegexpMatchMedium_1K-4 34.3µs ± 1% 34.3µs ± 1% ~ (p=0.871 n=23+22) RegexpMatchHard_32-4 1.67µs ± 1% 1.67µs ± 7% ~ (p=0.224 n=22+23) RegexpMatchHard_1K-4 51.5µs ± 1% 50.4µs ± 1% -1.99% (p=0.000 n=22+23) Revcomp-4 383ms ± 1% 415ms ± 0% +8.51% (p=0.000 n=22+22) Template-4 51.5ms ± 1% 51.5ms ± 1% ~ (p=0.555 n=20+23) TimeParse-4 279ns ± 2% 277ns ± 1% -0.95% (p=0.000 n=24+22) TimeFormat-4 294ns ± 1% 296ns ± 1% +0.58% (p=0.003 n=24+23) [Geo mean] 43.7µs 43.8µs +0.32% name old speed new speed delta GobDecode-4 134MB/s ± 1% 131MB/s ± 1% -2.32% (p=0.000 n=23+22) GobEncode-4 170MB/s ± 1% 157MB/s ± 1% -7.68% (p=0.000 n=22+22) Gzip-4 98.7MB/s ± 0% 96.1MB/s ± 1% -2.68% (p=0.000 n=23+24) Gunzip-4 590MB/s ± 7% 593MB/s ± 2% ~ (p=0.466 n=23+24) JSONEncode-4 141MB/s ± 1% 139MB/s ± 2% -1.13% (p=0.000 n=22+23) JSONDecode-4 40.9MB/s ± 1% 40.3MB/s ± 0% -1.47% (p=0.000 n=23+23) GoParse-4 20.1MB/s ± 1% 20.2MB/s ± 1% +0.69% (p=0.000 n=21+22) RegexpMatchEasy0_32-4 435MB/s ± 1% 444MB/s ± 2% +2.21% (p=0.000 n=21+22) RegexpMatchEasy0_1K-4 5.89GB/s ± 1% 5.89GB/s ± 1% ~ (p=0.439 n=22+24) RegexpMatchEasy1_32-4 445MB/s ± 1% 459MB/s ± 1% +3.06% (p=0.000 n=23+20) RegexpMatchEasy1_1K-4 3.26GB/s ± 1% 3.32GB/s ± 1% +1.97% (p=0.000 n=22+23) RegexpMatchMedium_32-4 9.40MB/s ± 1% 9.44MB/s ± 1% +0.43% (p=0.000 n=23+21) RegexpMatchMedium_1K-4 29.8MB/s ± 1% 29.8MB/s ± 1% ~ (p=0.826 n=23+22) RegexpMatchHard_32-4 19.1MB/s ± 1% 19.1MB/s ± 7% ~ (p=0.233 n=22+23) RegexpMatchHard_1K-4 19.9MB/s ± 1% 20.3MB/s ± 1% +2.03% (p=0.000 n=22+23) Revcomp-4 664MB/s ± 1% 612MB/s ± 0% -7.85% (p=0.000 n=22+22) Template-4 37.6MB/s ± 1% 37.7MB/s ± 1% ~ (p=0.558 n=20+23) [Geo mean] 134MB/s 133MB/s -0.76% Tue Mar 28 22:16:54 EDT 2017 Change-Id: I4a4f5c2b53d3fb85ef76c98522d3ed5cf8ae5b7e Reviewed-on: https://go-review.googlesource.com/38732Reviewed-by:
-
haya14busa authored
"go env" prints Go environment information as a shell script format by default but it's difficult for some tools (e.g. editor packages) to interpret it. The -json flag prints the environment in JSON format which can be easily interpreted by a lot of tools. $ go env -json { "CC": "gcc", "CGO_CFLAGS": "-g -O2", "CGO_CPPFLAGS": "", "CGO_CXXFLAGS": "-g -O2", "CGO_ENABLED": "1", "CGO_FFLAGS": "-g -O2", "CGO_LDFLAGS": "-g -O2", "CXX": "g++", "GCCGO": "gccgo", "GOARCH": "amd64", "GOBIN": "/home/haya14busa/go/bin", "GOEXE": "", "GOGCCFLAGS": "-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build498013955=/tmp/go-build -gno-record-gcc-switches", "GOHOSTARCH": "amd64", "GOHOSTOS": "linux", "GOOS": "linux", "GOPATH": "/home/haya14busa", "GORACE": "", "GOROOT": "/home/haya14busa/src/go.googlesource.com/go", "GOTOOLDIR": "/home/haya14busa/src/go.googlesource.com/go/pkg/tool/linux_amd64", "PKG_CONFIG": "pkg-config" } Also, it supports arguments with -json flag. $ go env -json GOROOT GOPATH GOBIN { "GOBIN": "/home/haya14busa/go/bin", "GOPATH": "/home/haya14busa", "GOROOT": "/home/haya14busa/src/go.googlesource.com/go" } Fixes #12567 Change-Id: I75db3780f14a8ab8c7fa58cc3c9cc488ef7b66a1 Reviewed-on: https://go-review.googlesource.com/38757Reviewed-by: -
Dave Cheney authored
gc.state.placeholder was added in 5a6e511c but never used. Change-Id: I5a621507279d5bb1f3991b7a412d9a63039c464e Reviewed-on: https://go-review.googlesource.com/38755Reviewed-by:
-
Dave Cheney authored
Make byteswapreg more Go like. Change-Id: Ibdf3603cae9cad2b3465b4c224a28a4c4c745c2e Reviewed-on: https://go-review.googlesource.com/38615 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 28 Mar, 2017 11 commits
-
-
Matthew Dempsky authored
Use namedfield consistently. Passes toolstash-check. Change-Id: Ic5a3acb4bfaa1f60dd2eac94612160509e8d7f94 Reviewed-on: https://go-review.googlesource.com/38741 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Automated refactoring using gofmt. Passes toolstash-check. Change-Id: I8624e1c231dc736e1bb4cc800acaf629a0af91d7 Reviewed-on: https://go-review.googlesource.com/38740 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
Prepared with gofmt -r. Passes toolstash-check. Change-Id: I8a4f7a8c365dfe464dfc5868a18c67d56af37749 Reviewed-on: https://go-review.googlesource.com/38739 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Ian Lance Taylor authored
Gccgo crashed compiling a function that returned multiple zero-sized values. Change-Id: I499112cc310e4a4f649962f4d2bc9fee95dee1b6 Reviewed-on: https://go-review.googlesource.com/38772Reviewed-by:
Than McIntosh <thanm@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ilya Tocar authored
This was cherry-picked to 1.8 as CL 38587, but on master issue was fixed by CL 37661. Add still relevant part (test) and close issue, since test passes. Fixes #19201 Change-Id: I6415792e2c465dc6d9bd6583ba1e54b107bcf5cc Reviewed-on: https://go-review.googlesource.com/37376 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Updates #19683 Change-Id: Ic00d5a9807200791cf37553f4f802dbf27beea19 Reviewed-on: https://go-review.googlesource.com/38770 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Prior to this CL, autotmps were global to a package. They also shared numbering with static variables. Switch autotmp numbering to be per-function instead, and do implicit numbering based on len(Func.Dcl). This eliminates a dependency on a global variable from the backend without adding to the Func struct. While we're here, move statuniqgen closer to its sole remaining user. This actually improves compiler performance, because the autotmp_* names can now be reused across functions. name old alloc/op new alloc/op delta Template 40.6MB ± 0% 40.1MB ± 0% -1.38% (p=0.000 n=10+10) Unicode 29.9MB ± 0% 29.9MB ± 0% ~ (p=0.912 n=10+10) GoTypes 116MB ± 0% 114MB ± 0% -1.53% (p=0.000 n=10+10) SSA 865MB ± 0% 856MB ± 0% -1.04% (p=0.000 n=10+10) Flate 25.8MB ± 0% 25.4MB ± 0% -1.36% (p=0.000 n=10+10) GoParser 32.2MB ± 0% 32.0MB ± 0% -0.72% (p=0.000 n=10+10) Reflect 80.3MB ± 0% 79.0MB ± 0% -1.65% (p=0.000 n=9+10) Tar 27.0MB ± 0% 26.7MB ± 0% -0.86% (p=0.000 n=10+9) XML 42.8MB ± 0% 42.4MB ± 0% -0.95% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 398k ± 1% 396k ± 1% -0.59% (p=0.002 n=10+10) Unicode 321k ± 1% 321k ± 0% ~ (p=0.912 n=10+10) GoTypes 1.17M ± 0% 1.16M ± 0% -0.77% (p=0.000 n=10+10) SSA 7.65M ± 0% 7.62M ± 0% -0.40% (p=0.000 n=10+10) Flate 240k ± 1% 238k ± 1% -0.56% (p=0.001 n=10+10) GoParser 323k ± 1% 320k ± 1% -0.65% (p=0.002 n=10+10) Reflect 1.01M ± 0% 1.00M ± 0% -0.37% (p=0.001 n=9+10) Tar 256k ± 1% 255k ± 0% ~ (p=0.101 n=10+8) XML 400k ± 1% 398k ± 1% ~ (p=0.063 n=10+10) Change-Id: I3c23ca98129137d373106990b1a3e1507bbe0cc3 Reviewed-on: https://go-review.googlesource.com/38729 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
It is currently possible in the compiler to create a struct type, calculate the widths of types that depend on it, and then alter the struct type. transformclosure has local protection against this. Protect against it at a deeper level. This is preparation to call dowidth automatically, rather than explicitly. This is a re-roll of CL 38469. Change-Id: Ic5b4baa250618504611fc57cbf51ab01d1eddf80 Reviewed-on: https://go-review.googlesource.com/38534 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Prior to this CL, Type.Width != 0 was the mark of a Type whose Width had been calculated. As a result, dowidth always recalculated the width of struct{}. This, combined with the prohibition on calculating the width of a FuncArgsStruct and the use of struct{} as a function argument, meant that there were circumstances in which it was forbidden to call dowidth on a type. This inhibits refactoring to call dowidth automatically, rather than explicitly. Instead add a helper method, Type.WidthCalculated, and implement as Type.Align > 0. Type.Width is not a good candidate for tracking whether the width has been calculated; 0 is a value type width, and Width is subject to too much magic value game-playing. For good measure, add a test for #11354. Change-Id: Ie9a9fb5d924e7a2010c1904ae5e38ed4a38eaeb2 Reviewed-on: https://go-review.googlesource.com/38468 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
haya14busa authored
It reduces needless allocations on compiling onepass regex. name old time/op new time/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 6.31µs ± 3% 6.11µs ± 3% ~ (p=0.056 n=5+5) CompileOnepass/^abcd$-4 5.69µs ±12% 4.93µs ± 4% -13.42% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a{0,})*?)$-4 7.10µs ±12% 5.82µs ± 5% -17.95% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a+)*)$-4 5.99µs ±10% 6.07µs ±11% ~ (p=1.000 n=5+5) CompileOnepass/^(?:(?:a|(?:aa)))$-4 7.36µs ± 4% 7.81µs ±19% ~ (p=0.310 n=5+5) CompileOnepass/^(?:[^\s\S])$-4 4.71µs ± 3% 4.71µs ± 5% ~ (p=1.000 n=5+5) CompileOnepass/^(?:(?:(?:a*)+))$-4 6.06µs ± 2% 6.23µs ± 9% ~ (p=0.310 n=5+5) CompileOnepass/^[a-c]+$-4 4.74µs ± 4% 4.64µs ± 6% ~ (p=0.421 n=5+5) CompileOnepass/^[a-c]*$-4 5.17µs ± 2% 4.68µs ± 0% -9.57% (p=0.016 n=5+4) CompileOnepass/^(?:a*)$-4 5.34µs ± 3% 5.08µs ±12% ~ (p=0.151 n=5+5) CompileOnepass/^(?:(?:aa)|a)$-4 7.24µs ± 5% 7.33µs ±12% ~ (p=0.841 n=5+5) CompileOnepass/^...$-4 5.28µs ± 3% 4.99µs ± 9% ~ (p=0.095 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 7.20µs ± 4% 7.24µs ±10% ~ (p=0.841 n=5+5) CompileOnepass/^a((b))c$-4 7.99µs ± 3% 7.76µs ± 8% ~ (p=0.151 n=5+5) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 8.30µs ± 5% 7.29µs ± 4% -12.08% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 7.34µs ± 4% 7.24µs ±19% ~ (p=0.690 n=5+5) CompileOnepass/^a(?:(b)|(c))c$-4 9.80µs ± 6% 9.49µs ±18% ~ (p=0.151 n=5+5) CompileOnepass/^a(?:b|c)$-4 5.23µs ± 3% 4.80µs ±10% ~ (p=0.056 n=5+5) CompileOnepass/^a(?:b?|c)$-4 8.26µs ± 3% 7.30µs ± 3% -11.62% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c+)$-4 9.18µs ± 2% 8.16µs ± 2% -11.06% (p=0.008 n=5+5) CompileOnepass/^a(?:bc)+$-4 6.16µs ± 3% 6.41µs ±13% ~ (p=0.548 n=5+5) CompileOnepass/^a(?:[bcd])+$-4 5.75µs ± 5% 5.50µs ±12% ~ (p=0.151 n=5+5) CompileOnepass/^a((?:[bcd])+)$-4 7.65µs ± 5% 6.93µs ± 9% ~ (p=0.056 n=5+5) CompileOnepass/^a(:?b|c)*d$-4 13.0µs ± 1% 12.1µs ± 2% -6.91% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 9.20µs ± 4% 8.25µs ± 3% -10.38% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 254µs ± 2% 220µs ± 6% -13.47% (p=0.008 n=5+5) name old alloc/op new alloc/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 3.92kB ± 0% 3.41kB ± 0% -13.06% (p=0.008 n=5+5) CompileOnepass/^abcd$-4 3.20kB ± 0% 2.75kB ± 0% -14.00% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a{0,})*?)$-4 3.85kB ± 0% 3.34kB ± 0% -13.31% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a+)*)$-4 3.46kB ± 0% 2.95kB ± 0% -14.78% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a|(?:aa)))$-4 4.20kB ± 0% 3.75kB ± 0% -10.67% (p=0.008 n=5+5) CompileOnepass/^(?:[^\s\S])$-4 3.10kB ± 0% 2.46kB ± 0% -20.62% (p=0.008 n=5+5) CompileOnepass/^(?:(?:(?:a*)+))$-4 3.64kB ± 0% 3.13kB ± 0% -14.07% (p=0.008 n=5+5) CompileOnepass/^[a-c]+$-4 3.06kB ± 0% 2.48kB ± 0% -18.85% (p=0.008 n=5+5) CompileOnepass/^[a-c]*$-4 3.10kB ± 0% 2.52kB ± 0% -18.60% (p=0.008 n=5+5) CompileOnepass/^(?:a*)$-4 3.21kB ± 0% 2.63kB ± 0% -17.96% (p=0.008 n=5+5) CompileOnepass/^(?:(?:aa)|a)$-4 4.09kB ± 0% 3.64kB ± 0% -10.96% (p=0.008 n=5+5) CompileOnepass/^...$-4 3.42kB ± 0% 2.91kB ± 0% -14.95% (p=0.008 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 4.09kB ± 0% 3.64kB ± 0% -10.96% (p=0.008 n=5+5) CompileOnepass/^a((b))c$-4 5.67kB ± 0% 4.39kB ± 0% -22.59% (p=0.008 n=5+5) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 5.73kB ± 0% 4.32kB ± 0% -24.58% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 5.41kB ± 0% 4.06kB ± 0% -24.85% (p=0.008 n=5+5) CompileOnepass/^a(?:(b)|(c))c$-4 6.40kB ± 0% 5.31kB ± 0% -17.00% (p=0.008 n=5+5) CompileOnepass/^a(?:b|c)$-4 3.46kB ± 0% 2.88kB ± 0% -16.67% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c)$-4 5.77kB ± 0% 4.36kB ± 0% -24.41% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c+)$-4 5.94kB ± 0% 4.59kB ± 0% -22.64% (p=0.008 n=5+5) CompileOnepass/^a(?:bc)+$-4 3.60kB ± 0% 3.15kB ± 0% -12.44% (p=0.008 n=5+5) CompileOnepass/^a(?:[bcd])+$-4 3.46kB ± 0% 2.94kB ± 0% -14.81% (p=0.008 n=5+5) CompileOnepass/^a((?:[bcd])+)$-4 5.50kB ± 0% 4.09kB ± 0% -25.62% (p=0.008 n=5+5) CompileOnepass/^a(:?b|c)*d$-4 7.24kB ± 0% 6.15kB ± 0% -15.03% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 5.75kB ± 0% 4.47kB ± 0% -22.25% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 225kB ± 0% 135kB ± 0% -39.99% (p=0.008 n=5+5) name old allocs/op new allocs/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 52.0 ± 0% 49.0 ± 0% -5.77% (p=0.008 n=5+5) CompileOnepass/^abcd$-4 44.0 ± 0% 41.0 ± 0% -6.82% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a{0,})*?)$-4 52.0 ± 0% 49.0 ± 0% -5.77% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a+)*)$-4 47.0 ± 0% 44.0 ± 0% -6.38% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a|(?:aa)))$-4 57.0 ± 0% 54.0 ± 0% -5.26% (p=0.008 n=5+5) CompileOnepass/^(?:[^\s\S])$-4 36.0 ± 0% 33.0 ± 0% -8.33% (p=0.008 n=5+5) CompileOnepass/^(?:(?:(?:a*)+))$-4 49.0 ± 0% 46.0 ± 0% -6.12% (p=0.008 n=5+5) CompileOnepass/^[a-c]+$-4 39.0 ± 0% 36.0 ± 0% -7.69% (p=0.008 n=5+5) CompileOnepass/^[a-c]*$-4 44.0 ± 0% 41.0 ± 0% -6.82% (p=0.008 n=5+5) CompileOnepass/^(?:a*)$-4 45.0 ± 0% 42.0 ± 0% -6.67% (p=0.008 n=5+5) CompileOnepass/^(?:(?:aa)|a)$-4 56.0 ± 0% 53.0 ± 0% -5.36% (p=0.008 n=5+5) CompileOnepass/^...$-4 46.0 ± 0% 43.0 ± 0% -6.52% (p=0.008 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 56.0 ± 0% 53.0 ± 0% -5.36% (p=0.008 n=5+5) CompileOnepass/^a((b))c$-4 57.0 ± 0% 53.0 ± 0% -7.02% (p=0.008 n=5+5) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 62.0 ± 0% 58.0 ± 0% -6.45% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 51.0 ± 0% 47.0 ± 0% -7.84% (p=0.008 n=5+5) CompileOnepass/^a(?:(b)|(c))c$-4 69.0 ± 0% 65.0 ± 0% -5.80% (p=0.008 n=5+5) CompileOnepass/^a(?:b|c)$-4 43.0 ± 0% 40.0 ± 0% -6.98% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c)$-4 61.0 ± 0% 57.0 ± 0% -6.56% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c+)$-4 67.0 ± 0% 63.0 ± 0% -5.97% (p=0.008 n=5+5) CompileOnepass/^a(?:bc)+$-4 49.0 ± 0% 46.0 ± 0% -6.12% (p=0.008 n=5+5) CompileOnepass/^a(?:[bcd])+$-4 46.0 ± 0% 43.0 ± 0% -6.52% (p=0.008 n=5+5) CompileOnepass/^a((?:[bcd])+)$-4 53.0 ± 0% 49.0 ± 0% -7.55% (p=0.008 n=5+5) CompileOnepass/^a(:?b|c)*d$-4 109 ± 0% 105 ± 0% -3.67% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 66.0 ± 0% 62.0 ± 0% -6.06% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 1.10k ± 0% 1.09k ± 0% -0.91% (p=0.008 n=5+5) Fixes #19735 Change-Id: Ic68503aaa08e42fafcf7e11cf1f584d674f5ea7b Reviewed-on: https://go-review.googlesource.com/38750Reviewed-by: -
Josh Bleecher Snyder authored
It is explicitly assigned in each of the assemblers as needed. I plan to remove Cursym entirely eventually, but this is a helpful intermediate step. Passes toolstash-check -all. Updates #15756 Change-Id: Id7ddefae2def439af44d03053886ca8cc935731f Reviewed-on: https://go-review.googlesource.com/38727 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
- 27 Mar, 2017 11 commits
-
-
Josh Bleecher Snyder authored
It is insufficiently canonical; see the discussion at issue 19719. Fixes #19719 Change-Id: I0559ff3b1b39d7bc4b446d104f36fdf8ce3da50e Reviewed-on: https://go-review.googlesource.com/38722 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Josh Bleecher Snyder authored
This eliminates references to lineno and other globals from ssa conversion. Passes toolstash-check. Updates #15756 Change-Id: I9792074fab0036b42f454b79139d0b27db913fb5 Reviewed-on: https://go-review.googlesource.com/38721 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
wei xiao authored
Fixes: #18070 Also added a test in: cmd/asm/internal/asm/testdata/arm64.s Change-Id: Icc43ff7383cc06b8eaccabd9ff0aefa61c4ecb88 Reviewed-on: https://go-review.googlesource.com/33595 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
Remove the global obj.Link.Curp. In asmz.go, replace the only use by passing it as an argument. In asm0.go and asm9.go, it was written but never read. In asm5.go and asm7.go, thread it through as an argument. Passes toolstash-check -all. Updates #15756 Change-Id: I1a0faa89e768820f35d73a8b37ec8088d78d15f7 Reviewed-on: https://go-review.googlesource.com/38715 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Fold the printing of the offending instruction into the neighboring Diag call, if it is not already present. Change-Id: I310f1479e16a4d2a24ff3c2f7e2c60e5e2015c1b Reviewed-on: https://go-review.googlesource.com/38714 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Elias Naur authored
The result from CFBundleCopyResourceURL is owned by the caller. This CL adds the necessary CFRelease to release it after use. Fixes #19722 Change-Id: I7afe22ef241d21922a7f5cef6498017e6269a5c3 Reviewed-on: https://go-review.googlesource.com/38639 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Josh Bleecher Snyder authored
The global encbuf helped avoid allocations. It is incompatible with a concurrent backend. To avoid a performance regression while removing it, introduce two optimizations. First, re-use a buffer in dwarf.PutFunc. Second, avoid a buffer entirely when the int being encoded fits in seven bits, which is about 75% of the time. Passes toolstash-check. Updates #15756 name old alloc/op new alloc/op delta Template 40.6MB ± 0% 40.6MB ± 0% -0.08% (p=0.001 n=8+9) Unicode 29.9MB ± 0% 29.9MB ± 0% ~ (p=0.068 n=8+10) GoTypes 116MB ± 0% 116MB ± 0% +0.05% (p=0.043 n=10+9) SSA 864MB ± 0% 864MB ± 0% +0.01% (p=0.010 n=10+9) Flate 25.8MB ± 0% 25.8MB ± 0% ~ (p=0.353 n=10+10) GoParser 32.2MB ± 0% 32.2MB ± 0% ~ (p=0.353 n=10+10) Reflect 80.2MB ± 0% 80.2MB ± 0% ~ (p=0.165 n=10+10) Tar 27.0MB ± 0% 26.9MB ± 0% ~ (p=0.143 n=10+10) XML 42.8MB ± 0% 42.8MB ± 0% ~ (p=0.400 n=10+9) name old allocs/op new allocs/op delta Template 398k ± 0% 397k ± 0% -0.20% (p=0.002 n=8+9) Unicode 320k ± 0% 321k ± 1% ~ (p=0.122 n=8+10) GoTypes 1.16M ± 0% 1.17M ± 0% ~ (p=0.053 n=10+9) SSA 7.65M ± 0% 7.65M ± 0% ~ (p=0.122 n=10+8) Flate 240k ± 1% 240k ± 1% ~ (p=0.243 n=10+9) GoParser 322k ± 1% 322k ± 1% ~ (p=0.481 n=10+10) Reflect 1.00M ± 0% 1.00M ± 0% ~ (p=0.211 n=9+10) Tar 256k ± 0% 255k ± 1% ~ (p=0.052 n=10+10) XML 400k ± 1% 400k ± 0% ~ (p=0.631 n=10+10) Change-Id: Ia39d9de09232fdbfc9c9cec14587bbf6939c9492 Reviewed-on: https://go-review.googlesource.com/38713 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Brad Fitzpatrick authored
If the user created an httptest.Server directly without using a constructor it won't have the new unexported 'client' field. So don't assume it's non-nil. Fixes #19729 Change-Id: Ie92e5da66cf4e7fb8d95f3ad0f4e3987d3ae8b77 Reviewed-on: https://go-review.googlesource.com/38710 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Kevin Burke <kev@inburke.com>
-
Austin Clements authored
We reused the old C stack check mechanism for the implementation of //go:systemstack, so when we execute a //go:systemstack function on a user stack, the system fails by calling morestackc. However, morestackc's message still talks about "executing C code". Fix morestackc's message to reflect its modern usage. Change-Id: I7e70e7980eab761c0520f675d3ce89486496030f Reviewed-on: https://go-review.googlesource.com/38572 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Elias Naur authored
On Android, the thread local offset is found by looping through memory starting at the TLS base address. The search is limited to PTHREAD_KEYS_MAX, but issue 19472 made it clear that in some cases, the slot is located further from the TLS base. The limit is merely a sanity check in case our assumptions about the thread-local storage layout are wrong, so this CL raises it to 384, which is enough for the test case in issue 19472. Fixes #19472 Change-Id: I89d1db3e9739d3a7fff5548ae487a7483c0a278a Reviewed-on: https://go-review.googlesource.com/38636 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Elias Naur authored
The proto_test tests are failing on NetBSD: https://build.golang.org/log/a3a577144ac48c6ef8e384ce6a700ad30549fb78 the failures seem similar to previous failures on Android: https://build.golang.org/log/b5786e0cd6d5941dc37b6a50be5172f6b99e22f0 The Android failures where fixed by CL 37896. This CL is an attempt to fix the NetBSD failures with a similar fix. Change-Id: I3834afa5b32303ca226e6a31f0f321f66fef9a3f Reviewed-on: https://go-review.googlesource.com/38637Reviewed-by:
-
- 26 Mar, 2017 2 commits
-
-
Josh Bleecher Snyder authored
Follow-up to CL 38668. Passes toolstash-check -all. Change-Id: I78a62509c610b5184b5e7ef2c4aa146fc8038840 Reviewed-on: https://go-review.googlesource.com/38670 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Josh Bleecher Snyder authored
Follow-up to CL 38446. Passes toolstash-check -all. Change-Id: I04cadc058cbaa5f396136502c574e5a395a33276 Reviewed-on: https://go-review.googlesource.com/38669 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
