Change-Id: I4718c82540ef214728393824b89c8c7f6656823b
Reviewed-on: https://go-review.googlesource.com/36210Reviewed-by: Russ Cox <rsc@golang.org>

This reverts commit cb6e0639.

The fix is incorrect as it's perfectly fine to refer to an
identifier 'init' inside a function, and 'init' may even be
a variable of function value. Misspelling 'init' in that
context would lead to an incorrect error message.

Reopened #8481.

Change-Id: I49787fdf7738213370ae6f0cab54013e9e3394a8
Reviewed-on: https://go-review.googlesource.com/37876
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Given

  (Store [c] (OffPtr <T1> [0] (Addr <T> _)) _
    (Store [c] (Addr <T> _) _ _))

dead store elimination doesn't eliminate the inner
Store, because it addresses a type of a different width
than the first store.

When decomposing StructMake operations, always generate
an OffPtr to address struct fields so that dead stores to
the first field of the struct can be optimized away.

benchmarks affected on darwin/amd64:
HTTPClientServer-8        73.2µs ± 1%    72.7µs ± 1%  -0.69%  (p=0.022 n=9+10)
TimeParse-8                304ns ± 1%     300ns ± 0%  -1.61%  (p=0.000 n=9+9)
RegexpMatchEasy1_32-8     80.1ns ± 0%    79.5ns ± 1%  -0.84%  (p=0.000 n=8+9)
GobDecode-8               6.78ms ± 0%    6.81ms ± 1%  +0.46%  (p=0.000 n=9+10)
Gunzip-8                  36.1ms ± 1%    36.2ms ± 0%  +0.37%  (p=0.019 n=10+10)
JSONEncode-8              15.6ms ± 0%    15.7ms ± 0%  +0.69%  (p=0.000 n=9+10)

Change-Id: Ia80d73fd047f9400c616ca64fdee4f438a0e7f21
Reviewed-on: https://go-review.googlesource.com/37769
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Found by github.com/mvdan/unparam.

Change-Id: I66f5a191cf9c9a11a7c3c4d7ee0a02e2c185f019
Reviewed-on: https://go-review.googlesource.com/37841Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Debugging support.

Change-Id: Ia518aaed36eaba76e6233306f718ad8aff3ce744
Reviewed-on: https://go-review.googlesource.com/37875Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Change-Id: I402383e893223facae451adbd640113126d5edd9
Reviewed-on: https://go-review.googlesource.com/37873
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Shrinks LSym somewhat for non-STEXT LSyms, which are much more common.

While here, switch to tracking Automs in a slice instead of a linked
list. (Previously, this would have made LSyms larger.)

Passes toolstash-check.

Change-Id: I082e50e1d1f1b544c9e06b6e412a186be6a4a2b5
Reviewed-on: https://go-review.googlesource.com/37872Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Instead, cmd/compile can directly emit R_USEFIELD relocations.

Manually verified rsc.io/tmp/fieldtrack still passes.

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

By clearing out t.nod in copytype, we effectively lose the reference
from a Type back to its declaring OTYPE Node. This means later in
typenamesym when we add typenod(t) to signatlist, we end up creating a
new OTYPE Node. Moreover, this Node's position information will depend
on whatever context it happens be needed, and will be used for the
Type's position in the export data.

Updates #19391.

Change-Id: Ied93126449f75d7c5e3275cbdcc6fa657a8aa21d
Reviewed-on: https://go-review.googlesource.com/37870
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

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

For historical reasons, it's still commonplace to iterate over the
slice returned by runtime.Callers and call FuncForPC on each PC. This
is broken in gccgo and somewhat broken in gc and will become more
broken in gc with mid-stack inlining.

In Go 1.7, we introduced runtime.CallersFrames to deal with these
problems, but didn't strongly direct people toward using it. Reword
the documentation on runtime.Callers to more strongly encourage people
to use CallersFrames and explicitly discourage them from iterating
over the PCs or using FuncForPC on the results.

Fixes #19426.

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

We're passed a pkg, so it makes little sense to not use it. This was
probably a typo and not the intended behaviour.

Fixes #19407.

Change-Id: Ia1c9130c0e474daf47753cf51914a2d7db272c96
Reviewed-on: https://go-review.googlesource.com/37839Reviewed-by: Robert Griesemer <gri@golang.org>

We don't need to start the goroutines if the program isn't going to do
any I/O.

Fixes #19390.

Change-Id: I47eef992d3ad05ed5f3150f4d6e5b3e0cb16a551
Reviewed-on: https://go-review.googlesource.com/37762
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Fix Decode to return the correct illegal data index from a corrupted
input that contains whitespaces.

Fixes #19406

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

Currently almost every function that deals with a *_func has to first
look up the *moduledata for the module containing the function's entry
point. This means we almost always do at least two identical module
lookups whenever we deal with a *_func (one to get the *_func and
another to get something from its module data) and sometimes several
more.

Fix this by making findfunc return a new funcInfo type that embeds
*_func, but also includes the *moduledata, and making all of the
functions that currently take a *_func instead take a funcInfo and use
the already-found *moduledata.

This transformation is trivial for the most part, since the *_func
type is usually inferred. The annoying part is that we can no longer
use nil to indicate failure, so this introduces a funcInfo.valid()
method and replaces nil checks with calls to valid.

Change-Id: I9b8075ef1c31185c1943596d96dec45c7ab5100f
Reviewed-on: https://go-review.googlesource.com/37331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

Updates the disassembler to support the same object file version used
by the assembler and linker.

Related #14782.

Change-Id: I4cd7560c4e4e1350cfb27ca9cbe0fde25fe693cc
Reviewed-on: https://go-review.googlesource.com/37797
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

golang.org/cl/37231 changed the object file format, but forgot to bump
the version string.

Change-Id: I8351ec8ed55e65479006e7c0df20254d0e31015f
Reviewed-on: https://go-review.googlesource.com/37798
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Found by github.com/mvdan/unparam.

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

For #16088.

Change-Id: Ib38bda06a5c5d110ca86510043775c5cf229e6a8
Reviewed-on: https://go-review.googlesource.com/37756Reviewed-by: Alan Donovan <adonovan@google.com>

For #16088.

Change-Id: I0ff480e95ef5af375be2ccc655f8b233a7bcd39d
Reviewed-on: https://go-review.googlesource.com/37755Reviewed-by: Alan Donovan <adonovan@google.com>

This will make type-checking more robust in the presence of import errors.

Also:
- import is now relative to directory containing teh file containing the import
  (matters for relative imports)
- factored out package import code from main resolver loop
- fixed a couple of minor bugs

Fixes #16088.

Change-Id: I1ace45c13cd0fa675d1762877cec0a30afd9ecdc
Reviewed-on: https://go-review.googlesource.com/37697
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently we acquire a global lock for every newMarkBits call. This is
unfortunate since every span sweep operation calls newMarkBits.

However, most allocations are simply linear allocations from the
current arena. Take advantage of this to add a lock-free fast path for
allocating from the current arena. With this change, the global lock
only protects the lists of arenas, not the free offset in the current
arena.

Change-Id: I6cf6182af8492c8bfc21276114c77275fe3d7826
Reviewed-on: https://go-review.googlesource.com/34595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Currently, newArena holds the gcBitsArenas lock across allocating
memory from the OS for a new gcBits arena. This is a global lock and
allocating physical memory can be expensive, so this has the potential
to cause high lock contention, especially since every single span
sweep operation calls newArena (via newMarkBits).

Improve the situation by temporarily dropping the lock across
allocation. This means the caller now has to revalidate its
assumptions after the lock is dropped, so this also factors out that
code path and reinvokes it after the lock is acquired.

Change-Id: I1113200a954ab4aad16b5071512583cfac744bdc
Reviewed-on: https://go-review.googlesource.com/34594
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

We generate a lot of pointless dead blocks
during the AST to SSA conversion.
There are a few commonly occurring kinds
of statements that contain neither variables
nor code and that switch to a new block themselves.
Stop making dead blocks for them.

For the code in #19379, this reduces compilation
wall time by 36% and max rss by 28%.

This also helps a little for regular code,
particularly code heavy on switch statements.

name       old time/op      new time/op      delta
Template        231ms ± 3%       230ms ± 5%    ~     (p=0.402 n=17+16)
Unicode         101ms ± 4%       103ms ± 5%    ~     (p=0.221 n=19+18)
GoTypes         635ms ± 5%       625ms ± 4%    ~     (p=0.063 n=20+18)
Compiler        2.93s ± 2%       2.89s ± 2%  -1.22%  (p=0.003 n=20+19)
SSA             4.53s ± 3%       4.52s ± 3%    ~     (p=0.380 n=20+19)
Flate           132ms ± 4%       133ms ± 5%    ~     (p=0.647 n=20+19)
GoParser        161ms ± 3%       161ms ± 4%    ~     (p=0.749 n=20+19)
Reflect         403ms ± 4%       397ms ± 3%  -1.53%  (p=0.030 n=20+19)
Tar             121ms ± 2%       121ms ± 8%    ~     (p=0.544 n=19+19)
XML             225ms ± 3%       224ms ± 4%    ~     (p=0.396 n=20+19)

name       old user-ns/op   new user-ns/op   delta
Template   302user-ms ± 1%  297user-ms ± 7%  -1.49%  (p=0.048 n=15+18)
Unicode    142user-ms ± 3%  143user-ms ± 5%    ~     (p=0.363 n=19+17)
GoTypes    852user-ms ± 5%  851user-ms ± 3%    ~     (p=0.851 n=20+18)
Compiler   4.11user-s ± 6%  3.98user-s ± 3%  -3.08%  (p=0.000 n=20+19)
SSA        6.91user-s ± 5%  6.82user-s ± 7%    ~     (p=0.113 n=20+19)
Flate      164user-ms ± 4%  168user-ms ± 4%  +2.42%  (p=0.001 n=18+19)
GoParser   207user-ms ± 4%  206user-ms ± 4%    ~     (p=0.176 n=20+18)
Reflect    509user-ms ± 4%  505user-ms ± 4%    ~     (p=0.113 n=20+19)
Tar        153user-ms ± 7%  151user-ms ± 9%    ~     (p=0.283 n=20+19)
XML        284user-ms ± 4%  282user-ms ± 4%    ~     (p=0.270 n=20+19)

name       old alloc/op     new alloc/op     delta
Template       42.6MB ± 0%      41.9MB ± 0%  -1.55%  (p=0.000 n=19+19)
Unicode        31.7MB ± 0%      31.7MB ± 0%    ~     (p=0.828 n=20+18)
GoTypes         124MB ± 0%       121MB ± 0%  -2.11%  (p=0.000 n=20+17)
Compiler        534MB ± 0%       523MB ± 0%  -2.06%  (p=0.000 n=20+19)
SSA             989MB ± 0%       977MB ± 0%  -1.28%  (p=0.000 n=20+19)
Flate          27.8MB ± 0%      27.5MB ± 0%  -0.98%  (p=0.000 n=20+19)
GoParser       34.3MB ± 0%      34.0MB ± 0%  -0.81%  (p=0.000 n=20+19)
Reflect        84.6MB ± 0%      82.9MB ± 0%  -2.00%  (p=0.000 n=17+18)
Tar            28.8MB ± 0%      28.3MB ± 0%  -1.52%  (p=0.000 n=16+18)
XML            47.2MB ± 0%      45.8MB ± 0%  -2.99%  (p=0.000 n=20+19)

name       old allocs/op    new allocs/op    delta
Template         421k ± 1%        419k ± 1%  -0.41%  (p=0.001 n=20+19)
Unicode          338k ± 1%        338k ± 1%    ~     (p=0.478 n=20+19)
GoTypes         1.28M ± 0%       1.28M ± 0%  -0.36%  (p=0.000 n=20+18)
Compiler        5.06M ± 0%       5.03M ± 0%  -0.63%  (p=0.000 n=20+19)
SSA             9.14M ± 0%       9.11M ± 0%  -0.34%  (p=0.000 n=20+19)
Flate            267k ± 1%        266k ± 1%    ~     (p=0.149 n=20+19)
GoParser         347k ± 0%        347k ± 1%    ~     (p=0.103 n=19+19)
Reflect         1.07M ± 0%       1.07M ± 0%  -0.42%  (p=0.000 n=16+18)
Tar              274k ± 0%        273k ± 1%    ~     (p=0.116 n=19+19)
XML              449k ± 0%        446k ± 1%  -0.60%  (p=0.000 n=20+19)

Updates #19379

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

This makes Sym flags consistent with the rest of the code after
the CL 37445.

No functional changes.

Passes toolstash -cmp.

Change-Id: Ica919f2ab98581371c717fff9a70aeb11058ca17
Reviewed-on: https://go-review.googlesource.com/37847Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Found by github.com/mvdan/unparam.

Change-Id: Ic97f05a2ecb5b17caa36aafe403e2266abea3e0e
Reviewed-on: https://go-review.googlesource.com/37836
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

On overloaded machines once we get to big N, the machine slowness dominates.
But we only retry once we get to a big N.
Instead, retry for small N too, and die on the first big N that fails.

Change-Id: I3ab9cfb88832ad86e2ba1389a926045091268aeb
Reviewed-on: https://go-review.googlesource.com/37543
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Found via github.com/mvdan/unparam.

Change-Id: I12cb0c35b14c880425c347fb3eb146712a86f310
Reviewed-on: https://go-review.googlesource.com/37834Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Found by github.com/mvdan/unparam.

Change-Id: I5b0c7cfdc1ab4fe0d79ef4c5a31612bbcf2ff3ad
Reviewed-on: https://go-review.googlesource.com/37833Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Found by github.com/mvdan/unparam.

Change-Id: Ie26e963176eb7afb35d16fed5cbca6530f7731c3
Reviewed-on: https://go-review.googlesource.com/37832Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I6343c162e27e2e492547c96f1fc504909b1c03c0
Reviewed-on: https://go-review.googlesource.com/37793Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Found by github.com/mvdan/unparam.

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

Found by github.com/mvdan/unparam. Small performance win when the
utf8.RuneLen call is removed.

name               old time/op    new time/op    delta
AppendQuoteRune-4    21.7ns ± 0%    21.4ns ± 0%  -1.38%  (p=0.008 n=5+5)

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

The assembler back end uses F15 as a temporary register in these
instructions.

Checked the assembler back end and made sure that this is the
only case clobbering F15.

Fixes #19403.

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

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

CL 37234 introduced string concatenation into some hot code. 
This CL does that work earlier and caches the result.

Updates #19386

Performance impact vs master:

name       old time/op      new time/op      delta
Template        223ms ± 5%       216ms ± 5%   -2.98%  (p=0.001 n=20+20)
Unicode        98.7ms ± 4%      99.0ms ± 4%     ~     (p=0.749 n=20+19)
GoTypes         631ms ± 4%       626ms ± 4%     ~     (p=0.253 n=20+20)
Compiler        2.91s ± 1%       2.87s ± 3%   -1.11%  (p=0.005 n=18+20)
SSA             4.48s ± 2%       4.36s ± 2%   -2.77%  (p=0.000 n=20+20)
Flate           130ms ± 2%       129ms ± 6%     ~     (p=0.428 n=19+20)
GoParser        160ms ± 4%       157ms ± 3%   -1.62%  (p=0.005 n=20+18)
Reflect         395ms ± 2%       394ms ± 4%     ~     (p=0.445 n=20+20)
Tar             120ms ± 5%       118ms ± 6%     ~     (p=0.101 n=19+20)
XML             224ms ± 3%       223ms ± 3%     ~     (p=0.544 n=19+19)

name       old user-ns/op   new user-ns/op   delta
Template   291user-ms ± 5%  265user-ms ± 5%   -9.02%  (p=0.000 n=20+19)
Unicode    140user-ms ± 3%  139user-ms ± 8%     ~     (p=0.904 n=20+20)
GoTypes    844user-ms ± 3%  849user-ms ± 3%     ~     (p=0.251 n=20+18)
Compiler   4.06user-s ± 5%  3.98user-s ± 2%     ~     (p=0.056 n=20+20)
SSA        6.89user-s ± 5%  6.50user-s ± 3%   -5.61%  (p=0.000 n=20+20)
Flate      164user-ms ± 5%  163user-ms ± 4%     ~     (p=0.365 n=20+19)
GoParser   206user-ms ± 6%  204user-ms ± 4%     ~     (p=0.534 n=20+18)
Reflect    501user-ms ± 4%  505user-ms ± 5%     ~     (p=0.383 n=20+20)
Tar        151user-ms ± 3%  152user-ms ± 7%     ~     (p=0.798 n=17+20)
XML        283user-ms ± 7%  280user-ms ± 5%     ~     (p=0.301 n=20+20)

name       old alloc/op     new alloc/op     delta
Template       42.5MB ± 0%      40.2MB ± 0%   -5.59%  (p=0.000 n=20+20)
Unicode        31.7MB ± 0%      31.0MB ± 0%   -2.19%  (p=0.000 n=20+18)
GoTypes         124MB ± 0%       117MB ± 0%   -5.90%  (p=0.000 n=20+20)
Compiler        533MB ± 0%       490MB ± 0%   -8.07%  (p=0.000 n=20+20)
SSA             989MB ± 0%       893MB ± 0%   -9.74%  (p=0.000 n=20+20)
Flate          27.8MB ± 0%      26.1MB ± 0%   -5.92%  (p=0.000 n=20+20)
GoParser       34.3MB ± 0%      32.1MB ± 0%   -6.43%  (p=0.000 n=19+20)
Reflect        84.6MB ± 0%      81.4MB ± 0%   -3.84%  (p=0.000 n=20+20)
Tar            28.8MB ± 0%      27.7MB ± 0%   -3.89%  (p=0.000 n=20+20)
XML            47.2MB ± 0%      44.2MB ± 0%   -6.45%  (p=0.000 n=20+19)

name       old allocs/op    new allocs/op    delta
Template         420k ± 1%        381k ± 1%   -9.35%  (p=0.000 n=20+20)
Unicode          338k ± 1%        324k ± 1%   -4.29%  (p=0.000 n=20+19)
GoTypes         1.28M ± 0%       1.15M ± 0%  -10.30%  (p=0.000 n=20+20)
Compiler        5.06M ± 0%       4.41M ± 0%  -12.92%  (p=0.000 n=20+20)
SSA             9.14M ± 0%       7.91M ± 0%  -13.46%  (p=0.000 n=19+20)
Flate            267k ± 0%        241k ± 1%   -9.53%  (p=0.000 n=20+20)
GoParser         347k ± 1%        312k ± 0%  -10.15%  (p=0.000 n=19+20)
Reflect         1.07M ± 0%       1.00M ± 0%   -6.86%  (p=0.000 n=20+20)
Tar              274k ± 1%        256k ± 1%   -6.73%  (p=0.000 n=20+20)
XML              448k ± 0%        398k ± 0%  -11.17%  (p=0.000 n=20+18)


Performance impact when applied together with CL 37234
atop CL 37234's parent commit (i.e. as if it were
a part of CL 37234), to show that this commit
makes CL 37234 completely performance-neutral:

name       old time/op      new time/op      delta
Template        222ms ±14%       222ms ±14%    ~     (p=1.000 n=14+15)
Unicode         104ms ±18%       106ms ±18%    ~     (p=0.650 n=13+14)
GoTypes         653ms ± 7%       638ms ± 5%    ~     (p=0.145 n=14+12)
Compiler        3.10s ± 1%       3.13s ±10%    ~     (p=1.000 n=2+2)
SSA             4.73s ±11%       4.68s ±11%    ~     (p=0.567 n=15+15)
Flate           136ms ± 4%       133ms ± 7%    ~     (p=0.231 n=12+14)
GoParser        163ms ±11%       169ms ±10%    ~     (p=0.352 n=14+14)
Reflect         415ms ±15%       423ms ±20%    ~     (p=0.715 n=15+14)
Tar             133ms ±17%       130ms ±23%    ~     (p=0.252 n=14+15)
XML             236ms ±16%       235ms ±14%    ~     (p=0.874 n=14+14)

name       old user-ns/op   new user-ns/op   delta
Template   271user-ms ±10%  271user-ms ±10%    ~     (p=0.780 n=14+15)
Unicode    143user-ms ± 5%  146user-ms ±11%    ~     (p=0.432 n=12+14)
GoTypes    864user-ms ± 5%  866user-ms ± 9%    ~     (p=0.905 n=14+13)
Compiler   4.17user-s ± 1%  4.26user-s ± 7%    ~     (p=1.000 n=2+2)
SSA        6.79user-s ± 8%  6.79user-s ± 6%    ~     (p=0.902 n=15+15)
Flate      169user-ms ± 8%  164user-ms ± 5%  -3.13%  (p=0.014 n=14+14)
GoParser   212user-ms ± 7%  217user-ms ±22%    ~     (p=1.000 n=13+15)
Reflect    521user-ms ± 7%  533user-ms ±15%    ~     (p=0.511 n=14+14)
Tar        165user-ms ±17%  161user-ms ±15%    ~     (p=0.345 n=15+15)
XML        294user-ms ±11%  292user-ms ±10%    ~     (p=0.839 n=14+14)

name       old alloc/op     new alloc/op     delta
Template       39.9MB ± 0%      39.9MB ± 0%    ~     (p=0.621 n=15+14)
Unicode        31.0MB ± 0%      31.0MB ± 0%    ~     (p=0.098 n=13+15)
GoTypes         117MB ± 0%       117MB ± 0%    ~     (p=0.775 n=15+15)
Compiler        488MB ± 0%       488MB ± 0%    ~     (p=0.333 n=2+2)
SSA             892MB ± 0%       892MB ± 0%  +0.03%  (p=0.000 n=15+15)
Flate          26.1MB ± 0%      26.1MB ± 0%    ~     (p=0.098 n=15+15)
GoParser       31.8MB ± 0%      31.8MB ± 0%    ~     (p=0.525 n=15+13)
Reflect        81.2MB ± 0%      81.2MB ± 0%  +0.06%  (p=0.001 n=12+14)
Tar            27.5MB ± 0%      27.5MB ± 0%    ~     (p=0.595 n=15+15)
XML            44.1MB ± 0%      44.1MB ± 0%    ~     (p=0.486 n=15+15)

name       old allocs/op    new allocs/op    delta
Template         378k ± 1%        378k ± 0%    ~     (p=0.949 n=15+14)
Unicode          324k ± 0%        324k ± 1%    ~     (p=0.057 n=14+15)
GoTypes         1.15M ± 0%       1.15M ± 0%    ~     (p=0.461 n=15+15)
Compiler        4.39M ± 0%       4.39M ± 0%    ~     (p=0.333 n=2+2)
SSA             7.90M ± 0%       7.90M ± 0%  +0.06%  (p=0.008 n=15+15)
Flate            240k ± 1%        241k ± 0%    ~     (p=0.233 n=15+15)
GoParser         309k ± 1%        309k ± 0%    ~     (p=0.867 n=15+12)
Reflect         1.00M ± 0%       1.00M ± 0%    ~     (p=0.139 n=12+15)
Tar              254k ± 1%        253k ± 1%    ~     (p=0.345 n=15+15)
XML              398k ± 0%        397k ± 1%    ~     (p=0.267 n=15+15)


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

If you cross compile for a Unix target and call user.Lookup("root")
or user.LookupId("0"), we'll try to read the answer out of
/etc/passwd instead of returning an "unimplemented" error.

The equivalent cgo function calls getpwuid_r in glibc, which
may reach out to the NSS database or allow callers to register
extensions. The pure Go implementation only reads from /etc/passwd.

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

Match more patterns generated by the compiler where the index for
a bound check is bounded through a AND operation, with different
register sizes.

These rules trigger a dozen of times in a bootstrap.

Change-Id: Ic9fff16f21d08580f19a366c3ee1a372e58357d1
Reviewed-on: https://go-review.googlesource.com/37442
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Currently ReadMemStats stops the world for ~1.7 ms/GB of heap because
it collects statistics from every single span. For large heaps, this
can be quite costly. This is particularly unfortunate because many
production infrastructures call this function regularly to collect and
report statistics.

Fix this by tracking the necessary cumulative statistics in the
mcaches. ReadMemStats still has to stop the world to stabilize these
statistics, but there are only O(GOMAXPROCS) mcaches to collect
statistics from, so this pause is only 25µs even at GOMAXPROCS=100.

Fixes #13613.

Change-Id: I3c0a4e14833f4760dab675efc1916e73b4c0032a
Reviewed-on: https://go-review.googlesource.com/34937
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

The gcstats structure is no longer consumed by anything and no longer
tracks statistics that are particularly relevant to the concurrent
garbage collector. Remove it. (Having statistics is probably a good
idea, but these aren't the stats we need these days and we don't have
a way to get them out of the runtime.)

In preparation for #13613.

Change-Id: Ib63e2f9067850668f9dcbfd4ed89aab4a6622c3f
Reviewed-on: https://go-review.googlesource.com/34936
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>