An error occurred fetching the project authors.
- 16 Aug, 2016 2 commits
-
-
Keith Randall authored
Fixes #16306 Change-Id: If8e2f411fe9a5a5c198f10765fee7261ba8feaf2 Reviewed-on: https://go-review.googlesource.com/24836 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Keith Randall authored
Might as well tell the runtime how large the map is going to be. This avoids grow work and allocations while the map is being built. Will wait for 1.8. Fixes #15880 Fixes #16279 Change-Id: I377e3e5ec1e2e76ea2a50cc00810adda20ad0e79 Reviewed-on: https://go-review.googlesource.com/23558 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 27 May, 2016 2 commits
-
-
Russ Cox authored
As in the elimination of PHEAP|PPARAM in CL 23393, this is something the front end can trivially take care of and then not bother the back ends with. It also eliminates some suspect (and only lightly exercised) code paths in the back ends. I don't have a smoking gun for this one but it seems more clearly correct. Change-Id: I3b3f5e669b3b81d091ff1e2fb13226a6f14c69d5 Reviewed-on: https://go-review.googlesource.com/23431Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The liveness computation of parameters generally was never correct, but forcing all parameters to be live throughout the function covered up that problem. The new SSA back end is too clever: even though it currently keeps the parameter values live throughout the function, it may find optimizations that mean the current values are not written back to the original parameter stack slots immediately or ever (for example if a parameter is set to nil, SSA constant propagation may replace all later uses of the parameter with a constant nil, eliminating the need to write the nil value back to the stack slot), so the liveness code must now track the actual operations on the stack slots, exposing these problems. One small problem in the handling of arguments is that nodarg can return ONAME PPARAM nodes with adjusted offsets, so that there are actually multiple *Node pointers for the same parameter in the instruction stream. This might be possible to correct, but not in this CL. For now, we fix this by using n.Orig instead of n when considering PPARAM and PPARAMOUT nodes. The major problem in the handling of arguments is general confusion in the liveness code about the meaning of PPARAM|PHEAP and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP. The difference between these two is that when a local variable "moves" to the heap, it's really just allocated there to start with; in contrast, when an argument moves to the heap, the actual data has to be copied there from the stack at the beginning of the function, and when a result "moves" to the heap the value in the heap has to be copied back to the stack when the function returns This general confusion is also present in the SSA back end. The PHEAP bit worked decently when I first introduced it 7 years ago (!) in 391425ae. The back end did nothing sophisticated, and in particular there was no analysis at all: no escape analysis, no liveness analysis, and certainly no SSA back end. But the complications caused in the various downstream consumers suggest that this should be a detail kept mainly in the front end. This CL therefore eliminates both the PHEAP bit and even the idea of "heap variables" from the back ends. First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP variable classes with the single PAUTOHEAP, a pseudo-class indicating a variable maintained on the heap and available by indirecting a local variable kept on the stack (a plain PAUTO). Second, walkexpr replaces all references to PAUTOHEAP variables with indirections of the corresponding PAUTO variable. The back ends and the liveness code now just see plain indirected variables. This may actually produce better code, but the real goal here is to eliminate these little-used and somewhat suspect code paths in the back end analyses. The OPARAM node type goes away too. A followup CL will do the same to PPARAMREF. I'm not sure that the back ends (SSA in particular) are handling those right either, and with the framework established in this CL that change is trivial and the result clearly more correct. Fixes #15747. Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74 Reviewed-on: https://go-review.googlesource.com/23393Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 25 Apr, 2016 1 commit
-
-
Josh Bleecher Snyder authored
As a nice side-effect, this allows us to unify several code paths. The terminology (low, high, max, simple slice expr, full slice expr) is taken from the spec and the examples in the spec. This is a trial run. The plan, probably for Go 1.8, is to change slice expressions to use Node.List instead of OKEY, and to do some similar tree structure changes for other ops. Passes toolstash -cmp. No performance change. all.bash passes with GO_GCFLAGS=-newexport. Updates #15350 Change-Id: Ic1efdc36e79cdb95ae1636e9817a3ac8f83ab1ac Reviewed-on: https://go-review.googlesource.com/22425Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
- 24 Apr, 2016 2 commits
-
-
Josh Bleecher Snyder authored
Passes toolstash -cmp. Change-Id: I915e76374fd64aa2597e6fa47e4fa95ca00ca643 Reviewed-on: https://go-review.googlesource.com/22380 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Keith Randall authored
func f(x, y, z *int) { a := []*int{x,y,z} ... } We used to use: var tmp [3]*int a := tmp[:] a[0] = x a[1] = y a[2] = z Now we do: var tmp [3]*int tmp[0] = x tmp[1] = y tmp[2] = z a := tmp[:] Doesn't sound like a big deal, but the compiler has trouble eliminating write barriers when using the former method because it doesn't know that the slice points to the stack. In the latter method, the compiler knows the array is on the stack and as a result doesn't emit any write barriers. This turns out to be extremely common when building ... args, like for calls fmt.Printf. Makes go binaries ~1% smaller. Doesn't have a measurable effect on the go1 fmt benchmarks, unfortunately. Fixes #14263 Update #6853 Change-Id: I9074a2788ec9e561a75f3b71c119b69f304d6ba2 Reviewed-on: https://go-review.googlesource.com/22395 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 22 Apr, 2016 2 commits
-
-
Matthew Dempsky authored
Change-Id: Ia3f262f06592b66447c213e2350402cd5e6e2ccd Reviewed-on: https://go-review.googlesource.com/22389 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Matthew Dempsky authored
Instead of switching on Ctype (which internally uses a type switch) and then scattering lots of type assertions throughout the CTFOO case clauses, just use type switches directly on the underlying constant value. Passes toolstash/buildall. Change-Id: I9bc172cc67e5f391cddc15539907883b4010689e Reviewed-on: https://go-review.googlesource.com/22384 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 21 Apr, 2016 1 commit
-
-
Matthew Dempsky authored
Instead of using TARRAY for both arrays and slices, create a new TSLICE kind to handle slices. Also, get rid of the "DDDArray" distinction. While kinda ugly, it seems likely we'll need to defer evaluating the constant bounds expressions for golang.org/issue/13890. Passes toolstash/buildall. Change-Id: I8e45d4900e7df3a04cce59428ec8b38035d3cc3a Reviewed-on: https://go-review.googlesource.com/22329Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 19 Apr, 2016 1 commit
-
-
Josh Bleecher Snyder authored
Previously, isStaticCompositeLiteral would return the wrong value for literals like: [1]struct{ b []byte }{b: []byte{1}} Note that the outermost component is an array, but once we recurse into isStaticCompositeLiteral, we never check again that arrays are actually arrays. Instead of adding more logic to the guts of isStaticCompositeLiteral, allow it to accept any Node and return the correct answer. Change-Id: I6af7814a9037bbc7043da9a96137fbee067bbe0e Reviewed-on: https://go-review.googlesource.com/22247Reviewed-by:
Keith Randall <khr@golang.org>
-
- 18 Apr, 2016 1 commit
-
-
Keith Randall authored
*p = [5]byte{1,2,3,4,5} First we allocate a global containing the RHS. Then we copy that global to a local stack variable, and then copy that local stack variable to *p. The intermediate copy is unnecessary. Note that this only works if the RHS is completely constant. If the code was: *p = [5]byte{1,2,x,4,5} this optimization doesn't apply as we have to construct the RHS on the stack before copying it to *p. Fixes #12841 Change-Id: I7cd0404ecc7a2d1750cbd8fe1222dba0fa44611f Reviewed-on: https://go-review.googlesource.com/22192Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 01 Apr, 2016 5 commits
-
-
Josh Bleecher Snyder authored
gorename -from '"cmd/compile/internal/gc".Node.Int' -to 'Int64' Change-Id: I2fe3bf9a26ae6b0600d990d0c981e4b8b53020a4 Reviewed-on: https://go-review.googlesource.com/21426Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
This removes all access to Type.Bound from outside type.go. Update sinit to make a new type rather than copy and mutate. Update bimport to create a new slice type instead of mutating TDDDFIELD. These are rare, so the extra allocs are nominal. I’m not happy about having a setter, but it appears the most practical route forward at the moment, and it only has a few uses. Passes toolstash -cmp. Change-Id: I174f07c8f336afc656904bde4bdbde4f3ef0db96 Reviewed-on: https://go-review.googlesource.com/21423 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Generated by eg. Passes toolstash -cmp. Change-Id: I7516c211ca9aacf824f74894671dc62d31763b01 Reviewed-on: https://go-review.googlesource.com/21422 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
This eliminates all direct reads of Type.Bound outside type.go. Change-Id: I0a9a72539f8f4c0de7f5e05e1821936bf7db5eb7 Reviewed-on: https://go-review.googlesource.com/21421 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
Added a debug flag "-d closure" to explain compilation of closures (should this be done some other way? Should we rewrite the "-m" flag to "-d escapes"?) Used this to discover that cause was an OXXX node in the captured vars list, and in turn noticed that OXXX nodes are explicitly ignored in all other processing of captured variables. Couldn't figure out a reproducer, did verify that this OXXX was not caused by an unnamed return value (which is one use of these). Verified lack of heap allocation by examining -S output. Assembly: (runtime/mgc.go:1371) PCDATA $0, $2 (runtime/mgc.go:1371) CALL "".notewakeup(SB) (runtime/mgc.go:1377) LEAQ "".gcBgMarkWorker.func1·f(SB), AX (runtime/mgc.go:1404) MOVQ AX, (SP) (runtime/mgc.go:1404) MOVQ "".autotmp_2242+88(SP), CX (runtime/mgc.go:1404) MOVQ CX, 8(SP) (runtime/mgc.go:1404) LEAQ go.string."GC worker (idle)"(SB), AX (runtime/mgc.go:1404) MOVQ AX, 16(SP) (runtime/mgc.go:1404) MOVQ $16, 24(SP) (runtime/mgc.go:1404) MOVB $20, 32(SP) (runtime/mgc.go:1404) MOVQ $0, 40(SP) (runtime/mgc.go:1404) PCDATA $0, $2 (runtime/mgc.go:1404) CALL "".gopark(SB) Added a check for compiling_runtime to ensure that this is caught in the future. Added a test to test the check. Verified that 1.5.3 did NOT reject the test case when compiled with -+ flag, so this is not a recently added bug. Cause of bug is two-part -- there was no leaking closure detection ever, and instead it relied on capture-of-variables to trigger compiling_runtime test, but closures improved in 1.5.3 so that mere capture of a value did not also capture the variable, which thus allowed closures to escape, as well as this case where the escape was spurious. In fixedbugs/issue14999.go, compare messages for f and g; 1.5.3 would reject g, but not f. 1.4 rejects both because 1.4 heap-allocates parameter x for both. Fixes #14999. Change-Id: I40bcdd27056810628e96763a44f2acddd503aee1 Reviewed-on: https://go-review.googlesource.com/21322 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
- 31 Mar, 2016 1 commit
-
-
Josh Bleecher Snyder authored
Generated by eg, manually fixed up. I’m not thrilled about having a setter, but given the variety of contexts in which this gets fiddled with, it is the cleanest available alternative. Change-Id: Ibdf23e638fe0bdabded014c9e59d557fab8c955f Reviewed-on: https://go-review.googlesource.com/21341Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
- 30 Mar, 2016 5 commits
-
-
Matthew Dempsky authored
This allows us to get rid of Isptr and Issigned. Still some code to clean up for Isint, Isfloat, and Iscomplex. CL produced mechanically using gofmt -w -r. Passes toolstash -cmp. Change-Id: If4f807bb7f2b357288d2547be2380eb511875786 Reviewed-on: https://go-review.googlesource.com/21339 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Matthew Dempsky authored
CL produced mechanically using gofmt -w -r. Passes toolstash -cmp. Change-Id: Ib2e8710ebd844e2149125b41c335b71a02fcab53 Reviewed-on: https://go-review.googlesource.com/21338 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
Replace Isfixedarray, Isslice, and Isinter with the IsArray, IsSlice, and IsInterface methods added for SSA. Rewrite performed mechanically using gofmt -w -r "Isfoo(t) -> t.IsFoo()". Because the IsFoo methods panic when given a nil pointer, a handful of call sites had to be modified to check for nil Type values. These aren't strictly necessary, because nil Type values should only occur in invalid Go source programs, so it would be okay if we panicked on them and gave up type checking the rest of the package. However, there are a couple regress tests that expect we continue, so add checks to keep those tests passing. (See #15029.) Passes toolstash -cmp. Change-Id: I511c6ac4cfdf3f9cbdb3e52a5fa91b6d09d82f80 Reviewed-on: https://go-review.googlesource.com/21336Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
This removes almost all direct access to Type’s heavily overloaded Type field. Mostly generated by eg, manually checked. Significant manual changes: * reflect.go's typPkg used Type indiscriminately. Use it only for specific etypes. * gen.go's visitComponents contained a usage of Type with structs. Using Type for structs no longer occurs, and the Fatal contained therein has not triggered, so it has been axed. * Scary code in cgen.go's cgen_slice is now explicitly scary. Passes toolstash -cmp. Change-Id: I2dbfb3c959da7ae239f964d83898c204affcabc6 Reviewed-on: https://go-review.googlesource.com/21331Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> 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
Changes generated by eg and manually checked. Isfixedarray, Isslice, and many other Type-related functions in subr.go should either be deleted or moved to type.go. Later, though; the game now is cleanup via encapsulation. Passes toolstash -cmp. Change-Id: I83dd8816f6263b74367d23c2719a08c362e330f9 Reviewed-on: https://go-review.googlesource.com/21303Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 29 Mar, 2016 3 commits
-
-
Josh Bleecher Snyder authored
These are the first of several convenience constructors for types. They are part of type field encapsulation. This removes most external writes to TARRAY Type and Bound fields. substAny still directly fiddles with the .Type field. substAny generally needs access to Type internals. It will be moved to type.go in a future CL. bimport still directly writes the .Type field. This is hard to change. Also of note: * inl.go contains an (apparently irrelevant) bug fix: as.Right was given the wrong type. vararrtype was previously unused. * I believe that aindex (subr.go) never creates slices, but it is safer to keep existing behavior. The removal of -1 as a constant there is part of hiding that implementation detail. Future CLs will finish that job. Passes toolstash -cmp. Change-Id: If09bf001a874d7dba08e9ad0bcd6722860af4b91 Reviewed-on: https://go-review.googlesource.com/21249Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> 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
Passes toolstash -cmp. Change-Id: I83af544974e1e91e0810e13321afb3e665dcdf12 Reviewed-on: https://go-review.googlesource.com/21248 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
This was the only unconverted instance. Change-Id: Ic0ba75824614fcd1e055316e62e26acd06801dd1 Reviewed-on: https://go-review.googlesource.com/21247 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
- 24 Mar, 2016 1 commit
-
-
Dave Cheney authored
Some minor scoping cleanups found by a very old version of grind. Change-Id: I1d373817586445fc87e38305929097b652696fdd Reviewed-on: https://go-review.googlesource.com/21064 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 22 Mar, 2016 1 commit
-
-
Josh Bleecher Snyder authored
Escape analysis has a hard time with tree-like structures (see #13493 and #14858). This is unlikely to change. As a result, when invoking a function that accepts a **Node parameter, we usually allocate a *Node on the heap. This happens a whole lot. This CL changes functions from taking a **Node to acting more like append: It both modifies the input and returns a replacement for it. Because of the cascading nature of escape analysis, in order to get the benefits, I had to modify almost all such functions. The remaining functions are in racewalk and the backend. I would be happy to update them as well in a separate CL. This CL was created by manually updating the function signatures and the directly impacted bits of code. The callsites were then automatically updated using a bespoke script: https://gist.github.com/josharian/046b1be7aceae244de39 For ease of reviewing and future understanding, this CL is also broken down into four CLs, mailed separately, which show the manual and the automated changes separately. They are CLs 20990, 20991, 20992, and 20993. Passes toolstash -cmp. name old time/op new time/op delta Template 335ms ± 5% 324ms ± 5% -3.35% (p=0.000 n=23+24) Unicode 176ms ± 9% 165ms ± 6% -6.12% (p=0.000 n=23+24) GoTypes 1.10s ± 4% 1.07s ± 2% -2.77% (p=0.000 n=24+24) Compiler 5.31s ± 3% 5.15s ± 3% -2.95% (p=0.000 n=24+24) MakeBash 41.6s ± 1% 41.7s ± 2% ~ (p=0.586 n=23+23) name old alloc/op new alloc/op delta Template 63.3MB ± 0% 62.4MB ± 0% -1.36% (p=0.000 n=25+23) Unicode 42.4MB ± 0% 41.6MB ± 0% -1.99% (p=0.000 n=24+25) GoTypes 220MB ± 0% 217MB ± 0% -1.11% (p=0.000 n=25+25) Compiler 994MB ± 0% 973MB ± 0% -2.08% (p=0.000 n=24+25) name old allocs/op new allocs/op delta Template 681k ± 0% 574k ± 0% -15.71% (p=0.000 n=24+25) Unicode 518k ± 0% 413k ± 0% -20.34% (p=0.000 n=25+24) GoTypes 2.08M ± 0% 1.78M ± 0% -14.62% (p=0.000 n=25+25) Compiler 9.26M ± 0% 7.64M ± 0% -17.48% (p=0.000 n=25+25) name old text-bytes new text-bytes delta HelloSize 578k ± 0% 578k ± 0% ~ (all samples are equal) CmdGoSize 6.46M ± 0% 6.46M ± 0% ~ (all samples are equal) name old data-bytes new data-bytes delta HelloSize 128k ± 0% 128k ± 0% ~ (all samples are equal) CmdGoSize 281k ± 0% 281k ± 0% ~ (all samples are equal) name old exe-bytes new exe-bytes delta HelloSize 921k ± 0% 921k ± 0% ~ (all samples are equal) CmdGoSize 9.86M ± 0% 9.86M ± 0% ~ (all samples are equal) Change-Id: I277d95bd56d51c166ef7f560647aeaa092f3f475 Reviewed-on: https://go-review.googlesource.com/20959Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 21 Mar, 2016 2 commits
-
-
Matthew Dempsky authored
Also give them more idiomatic Go names. Adding godocs is outside the scope of this CL. (Besides, the method names almost all directly parallel an underlying math/big.Int or math/big.Float method.) CL prepared mechanically with sed (for rewriting mpint.go/mpfloat.go) and gofmt (for rewriting call sites). Passes toolstash -cmp. Change-Id: Id76f4aee476ba740f48db33162463e7978c2083d Reviewed-on: https://go-review.googlesource.com/20909 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Brad Fitzpatrick authored
Introduce garbage-free LookupN to replace most users of Lookupf. Also, remove the string interning from LookupBytes which was hurting more than helping. name old alloc/op new alloc/op delta Template 63.0MB ± 0% 62.7MB ± 0% -0.48% (p=0.000 n=10+9) Unicode 43.0MB ± 0% 43.0MB ± 0% -0.17% (p=0.000 n=10+7) GoTypes 219MB ± 0% 218MB ± 0% -0.14% (p=0.000 n=10+10) Compiler 992MB ± 0% 991MB ± 0% -0.12% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 683k ± 0% 681k ± 0% -0.38% (p=0.000 n=10+8) Unicode 541k ± 0% 541k ± 0% -0.11% (p=0.000 n=10+10) GoTypes 2.09M ± 0% 2.08M ± 0% -0.40% (p=0.000 n=10+10) Compiler 9.28M ± 0% 9.24M ± 0% -0.36% (p=0.000 n=10+10) Size of $GOROOT/pkg/darwin_amd64 drops from 40124 KB to 40100 KB too, removing the zero padding as suggested by josharian. Updates #6853 Change-Id: I3c557266e9325fe29c459cef8e5b8954913e7abb Reviewed-on: https://go-review.googlesource.com/20931Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 19 Mar, 2016 1 commit
-
-
Ian Lance Taylor authored
The Node type ODOT and its variants all represent a selector, with a simple name to the right of the dot. Before this change this was represented by using an ONAME Node in the Right field. This ONAME node served no useful purpose. This CL changes these Node types to store the symbol in the Sym field instead, thus not requiring allocating a Node for each selector. When compiling x/tools/go/types this CL eliminates nearly 5000 calls to newname and reduces the total number of Nodes allocated by about 6.6%. It seems to cut compilation time by 1 to 2 percent. Getting this right was somewhat subtle, and I added two dubious changes to produce the exact same output as before. One is to ishairy in inl.go: the ONAME node increased the cost of ODOT and friends by 1, and I retained that, although really ODOT is not more expensive than any other node. The other is to varexpr in walk.go: because the ONAME in the Right field of an ODOT has no class, varexpr would always return false for an ODOT, although in fact for some ODOT's it seemingly ought to return true; I added an && false for now. I will send separate CLs, that will break toolstash -cmp, to clean these up. This CL passes toolstash -cmp. Change-Id: I4af8a10cc59078c436130ce472f25abc3a9b2f80 Reviewed-on: https://go-review.googlesource.com/20890 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 17 Mar, 2016 1 commit
-
-
Matthew Dempsky authored
Change-Id: I3c6035559288cfdc33857216f50241b81932c8a4 Reviewed-on: https://go-review.googlesource.com/20811 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 16 Mar, 2016 2 commits
-
-
Josh Bleecher Snyder authored
Follow-up to CL 20674. Passes toolstash -cmp. Change-Id: I065fd4cd80d996c1e6566773189401ca4630c1ca Reviewed-on: https://go-review.googlesource.com/20692 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
Passes toolstash -cmp. Change-Id: Ie11912a16d2cd54500e2f6e84316519b80e7c304 Reviewed-on: https://go-review.googlesource.com/20672Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 15 Mar, 2016 1 commit
-
-
Matthew Dempsky authored
The obj.Fmt* values are only used by gc/fmt.go, so just move them there. Also, add comments documenting the correspondance between FmtFoo names and their flag characters to make understanding the existing documentation slightly less confusing. While here, add a new FmtFlag named type to represent these values. Change-Id: I9631214b892557d094823f1ac575d0c43a84007b Reviewed-on: https://go-review.googlesource.com/20717 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 14 Mar, 2016 5 commits
-
-
Matthew Dempsky authored
Allows removing a bunch of unnecessary fields. Passes toolstash/buildall. Change-Id: Iec2492920e1c3ef352a9bf4296c74a55d9cc9ad6 Reviewed-on: https://go-review.googlesource.com/20677Reviewed-by:
Robert Griesemer <gri@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Currently, the only use for this is on the Left side of OKEY nodes within struct literals. esc and fmt only care so they can recognize that the ONAME nodes are actually field names, which need special handling. sinit additionally needs to know the field's offset within the struct, which we can provide via Xoffset. Passes toolstash/buildall. Change-Id: I362d965e161f4d80fcd9c9bae0dfacc657dc0b29 Reviewed-on: https://go-review.googlesource.com/20676Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Passes toolstash -cmp. Change-Id: Id16009ef3ef1173eafe0f0c578dbf325b61aab3c Reviewed-on: https://go-review.googlesource.com/20674 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Switch TSTRUCT and TINTER to use Fields instead of Type, which wrings out the remaining few direct uses of the latter. Preparation for converting fields to use a separate "Field" type. Passes toolstash/buildall. Change-Id: I5a2ea7e159d0dde1be2c9afafc10a8f739d95743 Reviewed-on: https://go-review.googlesource.com/20675 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Josh Bleecher Snyder authored
Passes toolstash -cmp. Change-Id: Iaa0d78c2552efb29e67f6c99c7287f8566027add Reviewed-on: https://go-review.googlesource.com/20673Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-