Commits · 7bf0adc6add500054ccbc37a868ab0fab120fa24 · go / golang

29 Mar, 2017 11 commits

runtime: include inlined calls in result of CallersFrames · 7bf0adc6

David Lazar authored Mar 08, 2017

Change-Id: If1a3396175f2afa607d56efd1444181334a9ae3e
Reviewed-on: https://go-review.googlesource.com/37862Reviewed-by: Austin Clements <austin@google.com>

7bf0adc6

runtime: handle inlined calls in runtime.Callers · ee97216a

David Lazar authored Mar 06, 2017

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: Austin Clements <austin@google.com>

ee97216a

test: allow flags in run action · f3f5b10e

David Lazar authored Mar 14, 2017

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: Austin Clements <austin@google.com>

f3f5b10e

cmd/go: build test binaries with -s in addition to -w · 94c95d3e

Russ Cox authored Mar 29, 2017

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>

94c95d3e

net, net/http: adjust time-in-past constant even earlier · 6983b9a5

Brad Fitzpatrick authored Mar 29, 2017

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>

6983b9a5

cmd/compile: automatically handle commuting ops in rewrite rules · 041ecb69

Keith Randall authored Mar 25, 2017

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>

041ecb69

reflect: fix out-of-bounds pointers calling no-result method · 627798db

Austin Clements authored Mar 28, 2017

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>

627798db

runtime: redo insert/remove of large spans · 6e9ec141

Rick Hudson authored Mar 27, 2017

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: Russ Cox <rsc@golang.org>

6e9ec141

cmd/go: add -json flag to go env · 846f9254

haya14busa authored Mar 29, 2017

"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: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

846f9254

cmd/compile/internal/gc: remove unused state.placeholder field · 9f232c17

Dave Cheney authored Mar 28, 2017

gc.state.placeholder was added in 5a6e511c but never used.

Change-Id: I5a621507279d5bb1f3991b7a412d9a63039c464e
Reviewed-on: https://go-review.googlesource.com/38755Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

9f232c17

cmd/internal/obj/x86: clean up byteswapreg · 54af1870

Dave Cheney authored Mar 27, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>

54af1870

28 Mar, 2017 11 commits

cmd/compile/internal/gc: cleanup selecttype · b72636cb

Matthew Dempsky authored Mar 28, 2017

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>

b72636cb

cmd/compile/internal/gc: use anonfield and namedfield · 3c0072e0

Matthew Dempsky authored Mar 28, 2017

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: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

3c0072e0

cmd/compile/internal/gc: npos(p, nod(o, l, r)) -> nodl(p, o, l, r) · 3f4f119b

Matthew Dempsky authored Mar 28, 2017

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: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

3f4f119b

test: add test for gccgo compiler crash · 835b17c8

Ian Lance Taylor authored Mar 28, 2017

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>

835b17c8

test/fixedbugs: add a test for 19201 · 4b50c813

Ilya Tocar authored Feb 21, 2017

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: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>

4b50c813

cmd/compile: fix two instances of { lineno = ...; yyerror } · 95bfd927

Josh Bleecher Snyder authored Mar 28, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>

95bfd927

cmd/compile: number autotmps per-func, not per-package · b87fcc6e

Josh Bleecher Snyder authored Mar 28, 2017

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: Matthew Dempsky <mdempsky@google.com>

b87fcc6e

cmd/compile: strengthen SetFields/Width safety guarantee · 8ee2d5bc

Josh Bleecher Snyder authored Mar 23, 2017

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: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

8ee2d5bc

cmd/compile: add Type.WidthCalculated · 8dafdb1b

Josh Bleecher Snyder authored Mar 23, 2017

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: Matthew Dempsky <mdempsky@google.com>

8dafdb1b

regexp: reduce allocations at onePassCopy · f5c1926e

haya14busa authored Mar 28, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

f5c1926e

cmd/internal/obj: eliminate stray ctxt.Cursym write · aca58647

Josh Bleecher Snyder authored Mar 27, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

aca58647

27 Mar, 2017 11 commits

cmd/vet: remove Peek from list of canonical methods · 73912a1b

Josh Bleecher Snyder authored Mar 27, 2017

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>

73912a1b

cmd/compile: construct typename in walk instead of SSA conversion · a0d6d385

Josh Bleecher Snyder authored Mar 27, 2017

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: Matthew Dempsky <mdempsky@google.com>

a0d6d385

cmd/asm: add support to shift operands on arm64 · 579297e1

wei xiao authored Nov 28, 2016

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>

579297e1

cmd/internal/obj: eliminate Curp · 7e817859

Josh Bleecher Snyder authored Mar 27, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7e817859

cmd/internal/obj: remove prasm · 1acba7d4

Josh Bleecher Snyder authored Mar 27, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

1acba7d4

runtime/cgo: CFRelease result from CFBundleCopyResourceURL · 2b4274d6

Elias Naur authored Mar 27, 2017

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>

2b4274d6

cmd/internal/dwarf: remove global encbuf · f9783011

Josh Bleecher Snyder authored Mar 26, 2017

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 <bradfitz@golang.org>

f9783011

net/http/httptest: don't panic on Close of user-constructed Server value · 89ebe5bb

Brad Fitzpatrick authored Mar 27, 2017

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>

89ebe5bb

runtime: improve systemstack-on-Go stack message · 4234d1de

Austin Clements authored Mar 23, 2017

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: Ian Lance Taylor <iant@golang.org>

4234d1de

runtime/cgo: raise the thread-local storage slot search limit on Android · 0476c7a7

Elias Naur authored Mar 25, 2017

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: Ian Lance Taylor <iant@golang.org>

0476c7a7

runtime/pprof: fix proto tests on NetBSD · aa4c2ca3

Elias Naur authored Mar 25, 2017

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: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

aa4c2ca3

26 Mar, 2017 7 commits

cmd/internal/obj/x86: change AsmBuf.Lock to bool · 4909ecc4

Josh Bleecher Snyder authored Mar 26, 2017

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>

4909ecc4

cmd/internal/obj: eliminate Prog.Mode · cf2b32e7

Josh Bleecher Snyder authored Mar 26, 2017

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: Brad Fitzpatrick <bradfitz@golang.org>

cf2b32e7

cmd/internal/obj: move fields from obj.Link to x86.AsmBuf · 4f122e82

Josh Bleecher Snyder authored Mar 26, 2017

These fields are used to encode a single instruction.
Add them to AsmBuf, which is also per-instruction,
and which is not global.

Updates #15756

Change-Id: I0e5ea22ffa641b07291e27de6e2ff23b6dc534bd
Reviewed-on: https://go-review.googlesource.com/38668
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

4f122e82

cmd/internal/obj/x86: make ctxt.Cursym local · 166160b4

Josh Bleecher Snyder authored Mar 26, 2017

Thread it through as an argument instead of using a global.

Passes toolstash-check -all.

Updates #15756

Change-Id: Ia8c6ce09b43dbb2e6c7d889ded8dbaeb5366048d
Reviewed-on: https://go-review.googlesource.com/38667
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

166160b4

cmd/internal/obj/x86: remove ctxt.Curp references · c06679f7

Josh Bleecher Snyder authored Mar 26, 2017

Empirically, p == ctxt.Curp here.
A scan of (the thousands of lines of) asm6.go
shows no clear opportunity for them to diverge.

Passes toolstash-check -all.

Updates #15756

Change-Id: I9f5ee9585a850fbe24be3b851d8fdc2c966c65ce
Reviewed-on: https://go-review.googlesource.com/38665
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

c06679f7

cmd/compile: remove likely bits from generated assembly · 214be5b3

Keith Randall authored Mar 25, 2017

We don't need them any more since #15837 was fixed.

Fixes #19718

Change-Id: I13e46c62b321b2c9265f44c977b63bfb23163ca2
Reviewed-on: https://go-review.googlesource.com/38664
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

214be5b3

cmd/internal/obj: make x86's asmbuf a local variable · 2ebe1bdd

Josh Bleecher Snyder authored Mar 25, 2017

The x86 assembler requires a buffer to build
variable-length instructions.
It used to be an obj.Link field.
That doesn't play nicely with concurrent assembly.
Move the AsmBuf type to the x86 package,
where it belongs anyway,
and make it a local variable.

Passes toolstash-check -all.
No compiler performance impact.

Updates #15756

Change-Id: I8014e52145380bfd378ee374a0c971ee5bada917
Reviewed-on: https://go-review.googlesource.com/38663
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

2ebe1bdd