- 04 Apr, 2017 1 commit
-
-
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 19 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:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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 <khr@golang.org>
-
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:
David Chase <drchase@google.com>
-
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:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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:
Russ Cox <rsc@golang.org>
-
Daniel Martí authored
The example shouldn't rely on the existance of example_test.go. That breaks in the playground, which is what the "run" button in https://golang.org/pkg/go/parser/#example_ParseFile does. Make the example self-sufficient by using a small piece of source via a string literal instead. Fixes #19823. Change-Id: Ie8a3c6c5d00724e38ff727862b62e6a3621adc88 Reviewed-on: https://go-review.googlesource.com/39236 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
-
Josh Bleecher Snyder authored
In a concurrent backend, Ctxt.Lookup will need some form of concurrency protection, which will make it more expensive. This CL changes the pcln table builder to track filenames as strings rather than LSyms. Those strings are then converted into LSyms at the last moment, for writing the object file. This CL removes over 85% of the calls to Ctxt.Lookup in a run of make.bash. Passes toolstash-check. Updates #15756 Change-Id: I3c53deff6f16f2643169f3bdfcc7aca2ca58b0a4 Reviewed-on: https://go-review.googlesource.com/39291 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Russ Cox authored
When generating a random int8, uint8, int16, uint16, int32, uint32, quick.Value chooses among all possible values. But when generating a random int64 or uint64, it only chooses values in the range [-2⁶², 2⁶²) (even for uint64). It should, like for all the other integers, use the full range. If it had, this would have caught #19807 earlier. Instead it let us discover the presence of #19809. While we are here, also make the default source of randomness not completely deterministic. Fixes #19808. Change-Id: I070f852531c92b3670bd76523326c9132bfc9416 Reviewed-on: https://go-review.googlesource.com/39152 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
The header is literally Key: Value If the value or the key has leading or trailing spaces, those will be lost by the round trip. Found because testing/quick returns different values now. Change-Id: I0f574bdbb5990689509c24309854d8f814b5efa0 Reviewed-on: https://go-review.googlesource.com/39211 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Minor cleanup. This is the only such instance in the compiler. Change-Id: I4e8ecde57d71867c7e1ac4d17e2154a91dd262b0 Reviewed-on: https://go-review.googlesource.com/39209 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Updates #15756 Change-Id: Ic635812b324af926333122c02908cebfb24d7bce Reviewed-on: https://go-review.googlesource.com/39208 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
No particular need for this, but it's nice to enforce invariants when they are available. Change-Id: Ia6fa88dc4116f65dac2879509746e123e2c1862a Reviewed-on: https://go-review.googlesource.com/39201 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
nodfp is a global, so modifying it is unsafe in a concurrent backend. It is also not necessary, since the Used marks are only relevant for nodes in fn.Dcl. For good measure, mark nodfp as always used. Passes toolstash-check. Updates #15756 Change-Id: I5320459f5eced2898615a17b395a10c1064bcaf5 Reviewed-on: https://go-review.googlesource.com/39200 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 02 Apr, 2017 1 commit
-
-
Cherry Zhang authored
Dupok symbols may be defined in multiple packages. Its associated package is chosen sort of arbitrarily (the first containing package that the linker loads). Canonicalize its package to the package with which it will be laid down in text, which is the first package in dependency order that defines the symbol. So later passes (for example, trampoline insertion pass) know that the dupok symbol is laid down along with the package. Fixes #19764. Change-Id: I7cbc7474ff3016d5069c8b7be04af934abab8bc3 Reviewed-on: https://go-review.googlesource.com/39150 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by:
-
- 01 Apr, 2017 5 commits
-
-
Dave Cheney authored
Each architecture's Rconv function is only used inside its respective package, so it does not need to be exported. Change-Id: Ifbd629964d7a9edd66501d7cdf4750621d66d646 Reviewed-on: https://go-review.googlesource.com/39110 Run-TryBot: Dave Cheney <dave@cheney.net> Reviewed-by:
-
Jamie Stackhouse authored
This change makes it possible to retrieve the size of a file part without having to Seek to determine file-size. Resolves #19501 Change-Id: I7b9994c4cf41c9b06a046eb7046f8952ae1f15e9 Reviewed-on: https://go-review.googlesource.com/39223Reviewed-by:
-
Emmanuel Odeke authored
Replace yyerror usages with yyerrorl in function typecheckswitch. Updates #19683. Change-Id: I7188cdecddd2ce4e06b8cee45b57f3765a979405 Reviewed-on: https://go-review.googlesource.com/38597Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Robert Griesemer authored
For #13560. Change-Id: I884e63f89d0756ca87b8c2092b4fd8360f791a2f Reviewed-on: https://go-review.googlesource.com/39171 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
For backend concurrency safety. Follow-up to CL 38721. This does introduce a Nodes where there wasn't one before, but these are so rare that the performance impact is negligible. Does not pass toolstash-check, but the only change is line numbers, and the new line numbers appear preferable. Updates #15756 name old alloc/op new alloc/op delta Template 39.9MB ± 0% 39.9MB ± 0% ~ (p=0.841 n=5+5) Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5) GoTypes 113MB ± 0% 113MB ± 0% +0.09% (p=0.008 n=5+5) SSA 854MB ± 0% 855MB ± 0% ~ (p=0.222 n=5+5) Flate 25.3MB ± 0% 25.3MB ± 0% ~ (p=0.690 n=5+5) GoParser 31.8MB ± 0% 31.9MB ± 0% ~ (p=0.421 n=5+5) Reflect 78.2MB ± 0% 78.3MB ± 0% ~ (p=0.548 n=5+5) Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.690 n=5+5) XML 42.3MB ± 0% 42.3MB ± 0% ~ (p=0.222 n=5+5) name old allocs/op new allocs/op delta Template 391k ± 1% 391k ± 0% ~ (p=0.841 n=5+5) Unicode 320k ± 0% 320k ± 0% ~ (p=0.841 n=5+5) GoTypes 1.14M ± 0% 1.14M ± 0% +0.26% (p=0.008 n=5+5) SSA 7.60M ± 0% 7.60M ± 0% ~ (p=0.548 n=5+5) Flate 234k ± 0% 234k ± 1% ~ (p=1.000 n=5+5) GoParser 316k ± 1% 317k ± 0% ~ (p=0.841 n=5+5) Reflect 979k ± 0% 980k ± 0% ~ (p=0.690 n=5+5) Tar 251k ± 1% 251k ± 0% ~ (p=0.595 n=5+5) XML 394k ± 0% 393k ± 0% ~ (p=0.222 n=5+5) Change-Id: I237ae5502db4560f78ce021dc62f6d289797afd6 Reviewed-on: https://go-review.googlesource.com/39197 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 31 Mar, 2017 14 commits
-
-
Josh Bleecher Snyder authored
Follow-up to review comments on CL 39193. Change-Id: I7649af9d70ad73e039061a7a66fea416a7476192 Reviewed-on: https://go-review.googlesource.com/39199Reviewed-by:
-
Josh Bleecher Snyder authored
A few gc.Node ops may be shared across functions. The compiler is (mostly) already careful to avoid mutating them. However, from a concurrency perspective, replacing (say) an empty list with an empty list still counts as a mutation. One place this occurs is orderinit. Avoid it. This requires fixing one spot where shared nodes were mutated. It doesn't result in any functional or performance changes. Passes toolstash-check. Updates #15756 Change-Id: I63c93b31baeeac62d7574804acb6b7f2bc9d14a9 Reviewed-on: https://go-review.googlesource.com/39196 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lynn Boger authored
This change improves the performance for LoweredMove on ppc64le and ppc64. benchmark old ns/op new ns/op delta BenchmarkCopyFat8-16 0.93 0.69 -25.81% BenchmarkCopyFat12-16 2.61 1.85 -29.12% BenchmarkCopyFat16-16 9.68 1.89 -80.48% BenchmarkCopyFat24-16 4.48 1.85 -58.71% BenchmarkCopyFat32-16 6.12 1.82 -70.26% BenchmarkCopyFat64-16 21.2 2.70 -87.26% BenchmarkCopyFat128-16 29.6 3.97 -86.59% BenchmarkCopyFat256-16 52.6 13.4 -74.52% BenchmarkCopyFat512-16 97.1 18.7 -80.74% BenchmarkCopyFat1024-16 186 35.3 -81.02% BenchmarkAssertE2TLarge-16 14.2 5.06 -64.37% Fixes #19785 Change-Id: I7d5e0052712b75811c02c7d86c5112e5649ad782 Reviewed-on: https://go-review.googlesource.com/38950Reviewed-by:
-
Russ Cox authored
Round uses r+r < d to decide whether the remainder is above or below half of d (to decide whether to round up or down). This is wrong when r+r wraps negative, because it looks < d but is really > d. No one will ever care about rounding to a multiple of d > 2⁶² (about 146 years), but might as well get it right. Fixes #19807. Change-Id: I1b55a742dc36e02a7465bc778bf5dd74fe71f7c0 Reviewed-on: https://go-review.googlesource.com/39151 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
The node in typenamesym requires neither a position nor a curfn. Passes toolstash-check. Updates #15756 Change-Id: I6d39a8961e5578fe5924aaceb29045b6de2699df Reviewed-on: https://go-review.googlesource.com/39194 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
For concurrency safety. Passes toolstash-check. Updates #15756. Change-Id: I1caca231a962781ff8f4f589b2e0454d2820ffb6 Reviewed-on: https://go-review.googlesource.com/39192 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
newnamel is newname but with no dependency on lineno or Curfn. This makes it suitable for use in a concurrent back end. Use it now to make tempAt global-free. The decision to push the assignment to n.Name.Curfn to the caller of newnamel is based on mdempsky's comments in #19683 that he'd like to do that for callers of newname as well. Passes toolstash-check. No compiler performance impact. Updates #19683 Updates #15756 Change-Id: Idc461a1716916d268c9ff323129830d9a6e4a4d9 Reviewed-on: https://go-review.googlesource.com/39191 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This causes a minor reduction in allocations, because the old funcdatasym names were being interned unnecessarily. Updates #15756 name old alloc/op new alloc/op delta Template 39.9MB ± 0% 39.9MB ± 0% ~ (p=0.280 n=10+10) Unicode 29.9MB ± 0% 29.8MB ± 0% -0.26% (p=0.000 n=10+10) GoTypes 113MB ± 0% 113MB ± 0% -0.12% (p=0.000 n=10+10) SSA 855MB ± 0% 855MB ± 0% -0.03% (p=0.001 n=10+10) Flate 25.4MB ± 0% 25.3MB ± 0% -0.30% (p=0.000 n=10+10) GoParser 31.9MB ± 0% 31.8MB ± 0% ~ (p=0.065 n=10+9) Reflect 78.4MB ± 0% 78.2MB ± 0% -0.15% (p=0.000 n=9+10) Tar 26.7MB ± 0% 26.7MB ± 0% -0.17% (p=0.000 n=9+10) XML 42.3MB ± 0% 42.4MB ± 0% +0.07% (p=0.011 n=10+10) name old allocs/op new allocs/op delta Template 390k ± 0% 390k ± 0% ~ (p=0.905 n=9+10) Unicode 319k ± 1% 319k ± 1% ~ (p=0.724 n=10+10) GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.393 n=10+10) SSA 7.60M ± 0% 7.60M ± 0% ~ (p=0.604 n=9+10) Flate 235k ± 1% 234k ± 1% ~ (p=0.105 n=10+10) GoParser 317k ± 0% 316k ± 1% ~ (p=0.280 n=10+10) Reflect 979k ± 0% 979k ± 0% ~ (p=0.315 n=10+10) Tar 251k ± 0% 251k ± 1% ~ (p=0.762 n=8+10) XML 393k ± 0% 394k ± 1% ~ (p=0.095 n=9+10) name old text-bytes new text-bytes delta HelloSize 684k ± 0% 684k ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 138k ± 0% 138k ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.03M ± 0% 1.03M ± 0% ~ (all equal) Change-Id: Idba33da4e89c325984ac46e4852cf12e4a7fd1a9 Reviewed-on: https://go-review.googlesource.com/39032 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Convert yyerrors into Fatals. Remove the goto. Move variable declaration closer to use. Unify printing strings a bit. Convert an int param into a bool. Passes toolstash-check. No compiler performance impact. Change-Id: I9017681417b785cf8693d18b124ac4f1ff37f2b5 Reviewed-on: https://go-review.googlesource.com/39170 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
The names never occur more than once, so interning the results is counterproductive. The impact is not very big, but neither is the fix. name old time/op new time/op delta Unicode 90.2ms ± 3% 88.3ms ± 5% -2.10% (p=0.000 n=94+98) Change-Id: I1e3a24433db4ae0c9a6e98166568941824ff0779 Reviewed-on: https://go-review.googlesource.com/39193 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Also: Fix (testdata/gen/) copyGen.go, zeroGen.go, and arithConstGen.go to actually match (testdata/) copy.go, zero.go, and arithConst.go, all of which were manually edited in https://go-review.googlesource.com/20823 and https://go-review.googlesource.com/22748 despite the 'do not edit' (or perhaps because it was missing in the case of arithConst.go). For #13560. Change-Id: I366e1b521e51885e0d318ae848760e5e14ccd488 Reviewed-on: https://go-review.googlesource.com/39172Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I986f0c106e059455874692f5bfe2b5af25cf470e Reviewed-on: https://go-review.googlesource.com/39090 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, the SSA backend reported violations of the //go:nowritebarrier annotation immediately. This necessitated emitting errors during SSA compilation, which is not compatible with a concurrent backend. Instead, check for such violations later. We already save the data required to do a late check for violations of the //go:nowritebarrierrec annotation. Use the same data, and check //go:nowritebarrier at the same time. One downside to doing this is that now only a single violation will be reported per function. Given that this is for the runtime only, and violations are rare, this seems an acceptable cost. While we are here, remove several 'nerrors != 0' checks that are rendered pointless. Updates #15756 Fixes #19250 (as much as it ever can be) Change-Id: Ia44c4ad5b6fd6f804d9f88d9571cec8d23665cb3 Reviewed-on: https://go-review.googlesource.com/38973 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
We don't support stack frames over 2GB. Rather than detect this during backend compilation, check for it at the end of compilation. This is arguably a more accurate check anyway, since it takes into account the full frame, including local stack, arguments, and arch-specific rounding, although it's unlikely anyone would ever notice. Also, rather than reporting the error right away, take note of it and report it later, at the top level. This is not relevant now, but it will help with making the backend concurrent, as the append to the list of oversized functions can be cheaply protected by a plain mutex. Updates #15756 Updates #19250 Change-Id: Id3fa21906616d62e9dc66e27a17fd5f83304e96e Reviewed-on: https://go-review.googlesource.com/38972 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
