Change-Id: I08e33b92dd8a22e28ec15aa5753904aa8e1c71f5
Reviewed-on: https://go-review.googlesource.com/42031
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Now that it only takes small values.

Change-Id: I08086d392529d8775b470d65afc2475f8d0e7f4a
Reviewed-on: https://go-review.googlesource.com/42030
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Id152767c033c12966e9e12ae303b99f38776f919
Reviewed-on: https://go-review.googlesource.com/40987
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

It is not safe to modify Node.Opt in the backend.
Instead of using Node.Opt to store liveness variable indices, use a map.
This simplifies the code and makes it much more clearly race-free.
There are generally few such variables, so the maps are not a significant
source of allocations; this also remove some allocations from putting
int32s into interfaces.

Because map lookups are more expensive than interface value extraction,
reorder valueEffects to do the map lookup last.

The only remaining use of Node.Opt is now in esc.go.

Passes toolstash-check.

Fixes #20144

name        old alloc/op      new alloc/op      delta
Template         37.8MB ± 0%       37.9MB ± 0%    ~     (p=0.548 n=5+5)
Unicode          28.9MB ± 0%       28.9MB ± 0%    ~     (p=0.548 n=5+5)
GoTypes           110MB ± 0%        110MB ± 0%  +0.16%  (p=0.008 n=5+5)
Compiler          461MB ± 0%        462MB ± 0%  +0.08%  (p=0.008 n=5+5)
SSA              1.11GB ± 0%       1.11GB ± 0%  +0.11%  (p=0.008 n=5+5)
Flate            24.7MB ± 0%       24.7MB ± 0%    ~     (p=0.690 n=5+5)
GoParser         31.1MB ± 0%       31.1MB ± 0%    ~     (p=0.841 n=5+5)
Reflect          73.7MB ± 0%       73.8MB ± 0%  +0.23%  (p=0.008 n=5+5)
Tar              25.8MB ± 0%       25.7MB ± 0%    ~     (p=0.690 n=5+5)
XML              41.2MB ± 0%       41.2MB ± 0%    ~     (p=0.841 n=5+5)
[Geo mean]       71.9MB            71.9MB       +0.06%

name        old allocs/op     new allocs/op     delta
Template           385k ± 0%         384k ± 0%    ~     (p=0.548 n=5+5)
Unicode            344k ± 0%         343k ± 1%    ~     (p=0.421 n=5+5)
GoTypes           1.16M ± 0%        1.16M ± 0%    ~     (p=0.690 n=5+5)
Compiler          4.43M ± 0%        4.42M ± 0%    ~     (p=0.095 n=5+5)
SSA               9.86M ± 0%        9.84M ± 0%  -0.19%  (p=0.008 n=5+5)
Flate              238k ± 0%         238k ± 0%    ~     (p=1.000 n=5+5)
GoParser           321k ± 0%         320k ± 0%    ~     (p=0.310 n=5+5)
Reflect            956k ± 0%         956k ± 0%    ~     (p=1.000 n=5+5)
Tar                252k ± 0%         251k ± 0%    ~     (p=0.056 n=5+5)
XML                402k ± 1%         400k ± 1%  -0.57%  (p=0.032 n=5+5)
[Geo mean]         740k              739k       -0.19%

Change-Id: Id5916c9def76add272e89c59fe10968f0a6bb01d
Reviewed-on: https://go-review.googlesource.com/42135
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

It used to be simple, and then it got complicated for speed (to reduce
allocations, mostly), but that involved a mutex and hurt multi-core
performance, contending on the mutex.

A change was sent to try to improve that mutex contention in
https://go-review.googlesource.com/c/42110/2/src/net/http/server.go
but that introduced its own allocations (the string->interface{}
boxing for the sync.Map key), which runs counter to the whole point of
that statusLine function: to remove allocations.

Instead, make the code simple again and not have a mutex. It's a bit
slower for the single-core case, but nobody with a single-user HTTP
server cares about 50 nanoseconds:

name                  old time/op    new time/op    delta
ResponseStatusLine      37.5ns ± 2%    87.1ns ± 2%  +132.42%          (p=0.029 n=4+4)
ResponseStatusLine-2    63.1ns ± 1%    43.1ns ±12%   -31.67%          (p=0.029 n=4+4)
ResponseStatusLine-4    53.8ns ± 8%    40.2ns ± 2%   -25.29%          (p=0.029 n=4+4)

name                  old alloc/op   new alloc/op   delta
ResponseStatusLine      0.00B ±NaN%    0.00B ±NaN%      ~     (all samples are equal)
ResponseStatusLine-2    0.00B ±NaN%    0.00B ±NaN%      ~     (all samples are equal)
ResponseStatusLine-4    0.00B ±NaN%    0.00B ±NaN%      ~     (all samples are equal)

name                  old allocs/op  new allocs/op  delta
ResponseStatusLine       0.00 ±NaN%     0.00 ±NaN%      ~     (all samples are equal)
ResponseStatusLine-2     0.00 ±NaN%     0.00 ±NaN%      ~     (all samples are equal)
ResponseStatusLine-4     0.00 ±NaN%     0.00 ±NaN%      ~     (all samples are equal)

(Note the code could be even simpler with fmt.Fprintf, but that is
 relatively slow and involves a bunch of allocations getting arguments
 into interface{} for the call)

Change-Id: I1fa119132dbbf97a8e7204ce3e0707d433060da2
Reviewed-on: https://go-review.googlesource.com/42133
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>

Using 'go build -tags "foo,bar"' might seem to work when you wanted
-tags "foo bar", since they make up a single tag that doesn't exist and
the build is unaffected.

Instead, error on any tag that contains a comma.

Fixes #18800.

Change-Id: I6641e03e2ae121c8878d6301c4311aef97026b73
Reviewed-on: https://go-review.googlesource.com/41951
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #20158

Change-Id: Iefa9a33569eb805f5ab678d17c37787835bc7efa
Reviewed-on: https://go-review.googlesource.com/42134
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The comment for Cmd.Stdout and Cmd.Stderr says that it's safe to
set both to the same writer, but it doesn't say that this only
works when both writers are comparable.

This change updates the comment to explain that using a
non-comparable writer may still lead to a race.

Fixes #19804

Change-Id: I63b420034666209a2b6fab48b9047c9d07b825e2
Reviewed-on: https://go-review.googlesource.com/42052Reviewed-by: Ian Lance Taylor <iant@golang.org>

Profile labels added by the user using pprof.Do, if present will
be in a *labelMap stored in the unsafe.Pointer 'tag' field of
the profile map entry. This change extracts the labels from the tag
field and writes them to the profile proto.

Change-Id: Ic40fdc58b66e993ca91d5d5effe0e04ffbb5bc46
Reviewed-on: https://go-review.googlesource.com/39613
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

If g1 sets its labels and then they are copied into a profile buffer
and then g2 reads the profile buffer and inspects the labels,
the race detector must understand that g1's recording of the labels
happens before g2's use of the labels. Make that so.

Fixes race test failure in CL 39613.

Change-Id: Id7cda1c2aac6f8eef49213b5ca414f7154b4acfa
Reviewed-on: https://go-review.googlesource.com/42111
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>

Fixes #19885.

Change-Id: I55420aace1b0f714df2d6460d2d1595f6863dd06
Reviewed-on: https://go-review.googlesource.com/42023Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #19522.

Change-Id: Ib3cf0336e0bf91580d533704ec1a9d45eb0bf62d
Reviewed-on: https://go-review.googlesource.com/42020Reviewed-by: Rob Pike <r@golang.org>

Updates #20162

Change-Id: Ie289bae0d0be8430e492ac73fd6e6bf36991d4a1
Reviewed-on: https://go-review.googlesource.com/42130Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

More specifically, allow Unicode letters in the directories of GitHub
repositories, which can occur and don't have a valid reason to be
disallowed by go get.

Do so by using a predefined character class, the Unicode character
property class \p{L} that describes the Unicode characters that are
letters:

	http://www.regular-expressions.info/unicode.html#category

Since it's not possible to create GitHub usernames or repositories
containing Unicode letters at this time, those parts of the import path
are still restricted to ASCII letters only.

Fix name of tested func in t.Errorf messages.

Fixes #18660.

Change-Id: Ia0ef4742bfd8317d989ef1eb1d7065e382852fe2
Reviewed-on: https://go-review.googlesource.com/41822Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This simplifies the code a bit and provides a modest speedup for
Marshal with many CPUs.

updates #17973
updates #18177

name          old time/op    new time/op    delta
Marshal         15.8µs ± 1%    15.9µs ± 1%   +0.67%  (p=0.021 n=8+7)
Marshal-6       5.76µs ±11%    5.17µs ± 2%  -10.36%  (p=0.002 n=8+8)
Marshal-48      9.88µs ± 5%    7.31µs ± 6%  -26.04%  (p=0.000 n=8+8)
Unmarshal       44.7µs ± 3%    45.1µs ± 5%     ~     (p=0.645 n=8+8)
Unmarshal-6     12.1µs ± 7%    11.8µs ± 8%     ~     (p=0.442 n=8+8)
Unmarshal-48    18.7µs ± 3%    18.2µs ± 4%     ~     (p=0.054 n=7+8)

name          old alloc/op   new alloc/op   delta
Marshal         5.78kB ± 0%    5.78kB ± 0%     ~     (all equal)
Marshal-6       5.78kB ± 0%    5.78kB ± 0%     ~     (all equal)
Marshal-48      5.78kB ± 0%    5.78kB ± 0%     ~     (all equal)
Unmarshal       8.58kB ± 0%    8.58kB ± 0%     ~     (all equal)
Unmarshal-6     8.58kB ± 0%    8.58kB ± 0%     ~     (all equal)
Unmarshal-48    8.58kB ± 0%    8.58kB ± 0%     ~     (p=1.000 n=8+8)

name          old allocs/op  new allocs/op  delta
Marshal           23.0 ± 0%      23.0 ± 0%     ~     (all equal)
Marshal-6         23.0 ± 0%      23.0 ± 0%     ~     (all equal)
Marshal-48        23.0 ± 0%      23.0 ± 0%     ~     (all equal)
Unmarshal          189 ± 0%       189 ± 0%     ~     (all equal)
Unmarshal-6        189 ± 0%       189 ± 0%     ~     (all equal)
Unmarshal-48       189 ± 0%       189 ± 0%     ~     (all equal)

https://perf.golang.org/search?q=upload:20170427.5

Change-Id: I4ee95a99540d3e4e47e056fff18357efd2cd340a
Reviewed-on: https://go-review.googlesource.com/41991
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #20038

Change-Id: Id692790ea406892bbe29090d461356bac28b6150
Reviewed-on: https://go-review.googlesource.com/41333Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This is the same technique used in CL 24466. By adding a little bit of
size to the binary, we can remove a function call and gain a lot of
performance.

A raw array ([128]bool) would be faster, but is also be 128 bytes
instead of 16.

Running tip on a Mac:

name             old time/op    new time/op     delta
QuoteMetaAll-4      192ns ±12%      120ns ±11%   -37.27%  (p=0.000 n=10+10)
QuoteMetaNone-4     186ns ± 6%       64ns ± 6%   -65.52%  (p=0.000 n=10+10)

name             old speed      new speed       delta
QuoteMetaAll-4   73.2MB/s ±11%  116.6MB/s ±10%   +59.21%  (p=0.000 n=10+10)
QuoteMetaNone-4   139MB/s ± 6%    405MB/s ± 6%  +190.74%  (p=0.000 n=10+10)

Change-Id: I68ce9fe2ef1c28e2274157789b35b0dd6ae3efb5
Reviewed-on: https://go-review.googlesource.com/41495
Run-TryBot: Kevin Burke <kev@inburke.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I2d3c3c715d857305944cd96c45554a16cb7967e9
Reviewed-on: https://go-review.googlesource.com/42032Reviewed-by: David Symonds <dsymonds@golang.org>

Fixes #20133

Change-Id: Ic1a6eb35de1f9ddac9527335eb49bf0b52963b6a
Reviewed-on: https://go-review.googlesource.com/41992Reviewed-by: Rob Pike <r@golang.org>

Use it to ensure that dowidth is not called
from the backend on a type whose size
has not yet been calculated.

This is an alternative to CL 42016.

Change-Id: I8c7b4410ee4c2a68573102f6b9b635f4fdcf392e
Reviewed-on: https://go-review.googlesource.com/42018
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

This reverts commit 94d540a4.

Reason for revert: prefer something along the lines of CL 42018.

Change-Id: I876fe32e98f37d8d725fe55e0fd0ea429c0198e0
Reviewed-on: https://go-review.googlesource.com/42022
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Change-Id: Ia45f05c63611ade4fe605b389c404953a7afbd1d
Reviewed-on: https://go-review.googlesource.com/41837
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Id93e78f0c8bef125f124a0a919053208e24a63cd
Reviewed-on: https://go-review.googlesource.com/41836
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Now it's not very different from syscall_dragonfly.go in
golang.org/x/sys/unix repository.

Change-Id: I8dfd22e1ebce9dc2cc71ab9ab7f0c92d93b2b762
Reviewed-on: https://go-review.googlesource.com/41835
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This CL mainly moves some work to the switch on w.Op,
to make a follow-up change simpler and clearer.

Updates #19838

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

Node.Used was written to from the backend
concurrently with reads of Node.Class
for the same ONAME Nodes.
I do not know why it was not failing consistently
under the race detector, but it is a race.

This is likely also a problem with Node.HasVal and Node.HasOpt.
They will be handled in a separate CL.

Fix Used by moving it to gc.Name and making it a separate bool.
There was one non-Name use of Used, marking OLABELs as used.
That is no longer needed, now that goto and label checking
happens early in the front end.

Leave the getters and setters in place,
to ease changing the representation in the future
(or changing to an interface!).

Updates #20144

Change-Id: I9bec7c6d33dcb129a4cfa9d338462ea33087f9f7
Reviewed-on: https://go-review.googlesource.com/42015
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Type.Size and Type.Alignment are for the front end:
They calculate size and alignment if needed.

Type.MustSize and Type.MustAlignment are for the back end:
They call Fatal if size and alignment are not already calculated.

Most uses are of MustSize and MustAlignment,
but that's because the back end is newer,
and this API was added to support it.

This CL was mostly generated with sed and selective reversion.
The only mildly interesting bit is the change of the ssa.Type interface
and the supporting ssa dummy types.

Follow-up to review feedback on CL 41970.

Passes toolstash-check.

Change-Id: I0d9b9505e57453dae8fb6a236a07a7a02abd459e
Reviewed-on: https://go-review.googlesource.com/42016
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

dowidth is fundamentally unsafe to call from the back end;
it will cause data races.

Replace all calls to dowidth in the backend with
assertions that the width has been calculated.

Then fix all the cases in which that was not so,
including the cases from #20145.

Fixes #20145.

Change-Id: Idba3d19d75638851a30ec2ebcdb703c19da3e92b
Reviewed-on: https://go-review.googlesource.com/41970
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Many (most!) of the values of objapi.SymKind are used only in the linker, so
this creates a separate cmd/link/internal/ld.SymKind type, removes most values
from SymKind and maps one to the other when reading object files in the linker.

Two of the remaining objapi.SymKind values are only checked for, never set and
so will never be actually found but I wanted to keep this to the most
mechanical change possible.

Change-Id: I4bbc5aed6713cab3e8de732e6e288eb77be0474c
Reviewed-on: https://go-review.googlesource.com/40985
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Currently, the following two codes generate the identical dwarf info
for type Foo.

prog 1)
type Foo struct {
   Bar
}

prog 2)
type Foo struct {
   Bar Bar
}

This change adds a go-specific attribute DW_AT_go_embedded_field
to annotate each member entry. Its absence or false value indicates
the corresponding member is not an embedded field.

Update #20037

Change-Id: Ibcbd2714f3e4d97c7b523d7398f29ab2301cc897
Reviewed-on: https://go-review.googlesource.com/41873Reviewed-by: David Chase <drchase@google.com>

There's been one failure on the race builder so far,
before we started sorting functions by length.

The race detector can only detect actual races,
and ordering functions by length might reduce the odds
of catching some kinds of races. Give it more to chew on.

Updates #20144

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

Its sole use is in walk.go. 100% code movement.

gsubr.go increasingly contains backend-y things.
With a few more relocations, it could probably be
fruitfully renamed progs.go.

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

They were used only in esc.go. 100% code movement.

Also, remove the rather outdated comment at the top of gen.go.
It's not really clear what gen.go is for any more.

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

When a constant doesn't fit in a single instruction, use two
paired instructions instead of the constant pool.  For example

  ADD $0xaa00bb, R0, R1

Used to rewrite to:

  MOV ?(IP), R11
  ADD R11, R0, R1

Instead, do:

  ADD $0xaa0000, R0, R1
  ADD $0xbb, R1, R1

Same number of instructions.
Good:
  4 less bytes (no constant pool entry)
  One less load.
Bad:
  Critical path is one instruction longer.

It's probably worth it to avoid the loads, they are expensive.

Dave Cheney got us some performance numbers: https://perf.golang.org/search?q=upload:20170426.1
TL;DR mean 1.37% improvement.

Change-Id: Ib206836161fdc94a3962db6f9caa635c87d57cf1
Reviewed-on: https://go-review.googlesource.com/41612
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

This provides a significant speedup for encoding and decoding when
using many CPU cores.

name                        old time/op  new time/op  delta
EndToEndPipe                5.26µs ± 2%  5.38µs ± 7%     ~     (p=0.121 n=8+7)
EndToEndPipe-6              1.86µs ± 5%  1.80µs ±11%     ~     (p=0.442 n=8+8)
EndToEndPipe-48             1.39µs ± 2%  1.41µs ± 4%     ~     (p=0.645 n=8+8)
EndToEndByteBuffer          1.54µs ± 5%  1.57µs ± 5%     ~     (p=0.130 n=8+8)
EndToEndByteBuffer-6         620ns ± 6%   310ns ± 8%  -50.04%  (p=0.000 n=8+8)
EndToEndByteBuffer-48        506ns ± 4%   110ns ± 3%  -78.22%  (p=0.000 n=8+8)
EndToEndSliceByteBuffer      149µs ± 3%   153µs ± 5%   +2.80%  (p=0.021 n=8+8)
EndToEndSliceByteBuffer-6    103µs ±17%    31µs ±12%  -70.06%  (p=0.000 n=8+8)
EndToEndSliceByteBuffer-48  93.2µs ± 2%  18.0µs ± 5%  -80.66%  (p=0.000 n=7+8)
EncodeComplex128Slice       20.6µs ± 5%  20.9µs ± 8%     ~     (p=0.959 n=8+8)
EncodeComplex128Slice-6     4.10µs ±10%  3.75µs ± 8%   -8.58%  (p=0.004 n=8+7)
EncodeComplex128Slice-48    1.14µs ± 2%  0.81µs ± 2%  -28.98%  (p=0.000 n=8+8)
EncodeFloat64Slice          10.2µs ± 7%  10.1µs ± 6%     ~     (p=0.694 n=7+8)
EncodeFloat64Slice-6        2.01µs ± 6%  1.80µs ±11%  -10.30%  (p=0.004 n=8+8)
EncodeFloat64Slice-48        701ns ± 3%   408ns ± 2%  -41.72%  (p=0.000 n=8+8)
EncodeInt32Slice            11.8µs ± 7%  11.7µs ± 6%     ~     (p=0.463 n=8+7)
EncodeInt32Slice-6          2.32µs ± 4%  2.06µs ± 5%  -10.89%  (p=0.000 n=8+8)
EncodeInt32Slice-48          731ns ± 2%   445ns ± 2%  -39.10%  (p=0.000 n=7+8)
EncodeStringSlice           9.13µs ± 9%  9.18µs ± 8%     ~     (p=0.798 n=8+8)
EncodeStringSlice-6         1.91µs ± 5%  1.70µs ± 5%  -11.07%  (p=0.000 n=8+8)
EncodeStringSlice-48         679ns ± 3%   397ns ± 3%  -41.50%  (p=0.000 n=8+8)
EncodeInterfaceSlice         449µs ±11%   461µs ± 9%     ~     (p=0.328 n=8+8)
EncodeInterfaceSlice-6       503µs ± 7%    88µs ± 7%  -82.51%  (p=0.000 n=7+8)
EncodeInterfaceSlice-48      335µs ± 8%    22µs ± 1%  -93.55%  (p=0.000 n=8+7)
DecodeComplex128Slice       67.2µs ± 4%  67.0µs ± 6%     ~     (p=0.721 n=8+8)
DecodeComplex128Slice-6     22.0µs ± 8%  18.9µs ± 5%  -14.44%  (p=0.000 n=8+8)
DecodeComplex128Slice-48    46.8µs ± 3%  34.9µs ± 3%  -25.48%  (p=0.000 n=8+8)
DecodeFloat64Slice          39.4µs ± 4%  40.3µs ± 3%     ~     (p=0.105 n=8+8)
DecodeFloat64Slice-6        16.1µs ± 2%  11.2µs ± 7%  -30.64%  (p=0.001 n=6+7)
DecodeFloat64Slice-48       38.1µs ± 3%  24.0µs ± 7%  -37.10%  (p=0.000 n=8+8)
DecodeInt32Slice            39.1µs ± 4%  40.1µs ± 5%     ~     (p=0.083 n=8+8)
DecodeInt32Slice-6          16.3µs ±21%  10.6µs ± 1%  -35.17%  (p=0.000 n=8+7)
DecodeInt32Slice-48         36.5µs ± 6%  21.9µs ± 9%  -39.89%  (p=0.000 n=8+8)
DecodeStringSlice           82.9µs ± 6%  85.5µs ± 5%     ~     (p=0.121 n=8+7)
DecodeStringSlice-6         32.4µs ±11%  26.8µs ±16%  -17.37%  (p=0.000 n=8+8)
DecodeStringSlice-48        76.0µs ± 2%  57.0µs ± 5%  -25.02%  (p=0.000 n=8+8)
DecodeInterfaceSlice         718µs ± 4%   752µs ± 5%   +4.83%  (p=0.038 n=8+8)
DecodeInterfaceSlice-6       500µs ± 6%   165µs ± 7%  -66.95%  (p=0.000 n=7+8)
DecodeInterfaceSlice-48      470µs ± 5%   120µs ± 6%  -74.55%  (p=0.000 n=8+7)
DecodeMap                   3.29ms ± 5%  3.34ms ± 5%     ~     (p=0.279 n=8+8)
DecodeMap-6                 7.73ms ± 8%  7.53ms ±18%     ~     (p=0.779 n=7+8)
DecodeMap-48                7.46ms ± 6%  7.71ms ± 3%     ~     (p=0.161 n=8+8)

https://perf.golang.org/search?q=upload:20170426.4

Change-Id: I335874028ef8d7c991051004f8caadd16c92d5cc
Reviewed-on: https://go-review.googlesource.com/41872
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This provides a significant speedup when using reflection-heavy code
on many CPU cores, such as when marshaling or unmarshaling protocol
buffers.

updates #17973
updates #18177

name                       old time/op    new time/op     delta
Call                          239ns ±10%      245ns ± 7%       ~     (p=0.562 n=10+9)
Call-6                        201ns ±38%       48ns ±29%    -76.39%  (p=0.000 n=10+9)
Call-48                       133ns ± 8%       12ns ± 2%    -90.92%  (p=0.000 n=10+8)
CallArgCopy/size=128          169ns ±12%      197ns ± 2%    +16.35%  (p=0.000 n=10+7)
CallArgCopy/size=128-6        142ns ± 9%       34ns ± 7%    -76.10%  (p=0.000 n=10+9)
CallArgCopy/size=128-48       125ns ± 3%        9ns ± 7%    -93.01%  (p=0.000 n=8+8)
CallArgCopy/size=256          177ns ± 8%      197ns ± 5%    +11.24%  (p=0.000 n=10+9)
CallArgCopy/size=256-6        148ns ±11%       35ns ± 6%    -76.23%  (p=0.000 n=10+9)
CallArgCopy/size=256-48       127ns ± 4%        9ns ± 9%    -92.66%  (p=0.000 n=10+9)
CallArgCopy/size=1024         196ns ± 6%      228ns ± 7%    +16.09%  (p=0.000 n=10+9)
CallArgCopy/size=1024-6       143ns ± 6%       42ns ± 5%    -70.39%  (p=0.000 n=8+8)
CallArgCopy/size=1024-48      130ns ± 7%       10ns ± 1%    -91.99%  (p=0.000 n=10+8)
CallArgCopy/size=4096         330ns ± 9%      351ns ± 5%     +6.20%  (p=0.004 n=10+9)
CallArgCopy/size=4096-6       173ns ±14%       62ns ± 6%    -63.83%  (p=0.000 n=10+8)
CallArgCopy/size=4096-48      141ns ± 6%       15ns ± 6%    -89.59%  (p=0.000 n=10+8)
CallArgCopy/size=65536       7.71µs ±10%     7.74µs ±10%       ~     (p=0.859 n=10+9)
CallArgCopy/size=65536-6     1.33µs ± 4%     1.34µs ± 6%       ~     (p=0.720 n=10+9)
CallArgCopy/size=65536-48     347ns ± 2%      344ns ± 2%       ~     (p=0.202 n=10+9)
PtrTo                        30.2ns ±10%     41.3ns ±11%    +36.97%  (p=0.000 n=10+9)
PtrTo-6                       126ns ± 6%        7ns ±10%    -94.47%  (p=0.000 n=9+9)
PtrTo-48                     86.9ns ± 9%      1.7ns ± 9%    -98.08%  (p=0.000 n=10+9)
FieldByName1                 86.6ns ± 5%     87.3ns ± 7%       ~     (p=0.737 n=10+9)
FieldByName1-6               19.8ns ±10%     18.7ns ±10%       ~     (p=0.073 n=9+9)
FieldByName1-48              7.54ns ± 4%     7.74ns ± 5%     +2.55%  (p=0.023 n=9+9)
FieldByName2                 1.63µs ± 8%     1.70µs ± 4%     +4.13%  (p=0.020 n=9+9)
FieldByName2-6                481ns ± 6%      490ns ±10%       ~     (p=0.474 n=9+9)
FieldByName2-48               723ns ± 3%      736ns ± 2%     +1.76%  (p=0.045 n=8+8)
FieldByName3                 10.5µs ± 7%     10.8µs ± 7%       ~     (p=0.234 n=8+8)
FieldByName3-6               2.78µs ± 3%     2.94µs ±10%     +5.87%  (p=0.031 n=9+9)
FieldByName3-48              3.72µs ± 2%     3.91µs ± 5%     +4.91%  (p=0.003 n=9+9)
InterfaceBig                 10.8ns ± 5%     10.7ns ± 5%       ~     (p=0.849 n=9+9)
InterfaceBig-6               9.62ns ±81%     1.79ns ± 4%    -81.38%  (p=0.003 n=9+9)
InterfaceBig-48              0.48ns ±34%     0.50ns ± 7%       ~     (p=0.071 n=8+9)
InterfaceSmall               10.7ns ± 5%     10.9ns ± 4%       ~     (p=0.243 n=9+9)
InterfaceSmall-6             1.85ns ± 5%     1.79ns ± 1%     -2.97%  (p=0.006 n=7+8)
InterfaceSmall-48            0.49ns ±20%     0.48ns ± 5%       ~     (p=0.740 n=7+9)
New                          28.2ns ±20%     26.6ns ± 3%       ~     (p=0.617 n=9+9)
New-6                        4.69ns ± 4%     4.44ns ± 3%     -5.33%  (p=0.001 n=9+9)
New-48                       1.10ns ± 9%     1.08ns ± 6%       ~     (p=0.285 n=9+8)

name                       old alloc/op   new alloc/op    delta
Call                          0.00B           0.00B            ~     (all equal)
Call-6                        0.00B           0.00B            ~     (all equal)
Call-48                       0.00B           0.00B            ~     (all equal)

name                       old allocs/op  new allocs/op   delta
Call                           0.00            0.00            ~     (all equal)
Call-6                         0.00            0.00            ~     (all equal)
Call-48                        0.00            0.00            ~     (all equal)

name                       old speed      new speed       delta
CallArgCopy/size=128        757MB/s ±11%    649MB/s ± 1%    -14.33%  (p=0.000 n=10+7)
CallArgCopy/size=128-6      901MB/s ± 9%   3781MB/s ± 7%   +319.69%  (p=0.000 n=10+9)
CallArgCopy/size=128-48    1.02GB/s ± 2%  14.63GB/s ± 6%  +1337.98%  (p=0.000 n=8+8)
CallArgCopy/size=256       1.45GB/s ± 9%   1.30GB/s ± 5%    -10.17%  (p=0.000 n=10+9)
CallArgCopy/size=256-6     1.73GB/s ±11%   7.28GB/s ± 7%   +320.76%  (p=0.000 n=10+9)
CallArgCopy/size=256-48    2.00GB/s ± 4%  27.46GB/s ± 9%  +1270.85%  (p=0.000 n=10+9)
CallArgCopy/size=1024      5.21GB/s ± 6%   4.49GB/s ± 8%    -13.74%  (p=0.000 n=10+9)
CallArgCopy/size=1024-6    7.18GB/s ± 7%  24.17GB/s ± 5%   +236.64%  (p=0.000 n=9+8)
CallArgCopy/size=1024-48   7.87GB/s ± 7%  98.43GB/s ± 1%  +1150.99%  (p=0.000 n=10+8)
CallArgCopy/size=4096      12.3GB/s ± 6%   11.7GB/s ± 5%     -5.00%  (p=0.008 n=9+9)
CallArgCopy/size=4096-6    23.8GB/s ±16%   65.6GB/s ± 5%   +175.02%  (p=0.000 n=10+8)
CallArgCopy/size=4096-48   29.0GB/s ± 7%  279.6GB/s ± 6%   +862.87%  (p=0.000 n=10+8)
CallArgCopy/size=65536     8.52GB/s ±11%   8.49GB/s ± 9%       ~     (p=0.842 n=10+9)
CallArgCopy/size=65536-6   49.3GB/s ± 4%   49.0GB/s ± 6%       ~     (p=0.720 n=10+9)
CallArgCopy/size=65536-48   189GB/s ± 2%    190GB/s ± 2%       ~     (p=0.211 n=10+9)

https://perf.golang.org/search?q=upload:20170426.3

Change-Id: Iff68f18ef69defb7f30962e21736ac7685a48a27
Reviewed-on: https://go-review.googlesource.com/41871
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The "lldb start" phase often times out on the iOS builder. Increase
the timeout and see if that helps.

Change-Id: I92fd67cbfa90659600e713198d6b2c5c78dde20f
Reviewed-on: https://go-review.googlesource.com/41863Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #19976

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

The current code treats condition as special register and write
its raw data directly into instruction.

The fix converts the raw data into correct condition encoding.
Also fix the operand catogery of FCCMP.

Add tests to cover all cases.

Change-Id: Ib194041bd9017dd0edbc241564fe983082ac616b
Reviewed-on: https://go-review.googlesource.com/41511
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Fixes #20134

Change-Id: I92699d118c713179961c037a6bbbcbec4efa63ba
Reviewed-on: https://go-review.googlesource.com/41823
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>