This avoids expensive division calculations
for many common slice element sizes.

name                      old time/op  new time/op  delta
MakeSlice-8               51.9ns ± 3%  35.1ns ± 2%  -32.41%  (p=0.000 n=10+10)
GrowSliceBytes-8          44.1ns ± 2%  44.1ns ± 1%     ~     (p=0.984 n=10+10)
GrowSliceInts-8           60.9ns ± 3%  60.9ns ± 3%     ~     (p=0.698 n=10+10)
GrowSlicePtr-8             131ns ± 1%   120ns ± 2%   -8.41%   (p=0.000 n=8+10)
GrowSliceStruct24Bytes-8   111ns ± 2%   103ns ± 3%   -7.23%    (p=0.000 n=8+8)

Change-Id: I2630eb3d73c814db030cad16e620ea7fecbbd312
Reviewed-on: https://go-review.googlesource.com/22223Reviewed-by: Keith Randall <khr@golang.org>

This extends CL 22192.

This removes the remaining performance disparity
between non-SSA and SSA on the AppendInPlace benchmarks.

Going from non-SSA to SSA:

AppendInPlace/NoGrow/2Ptr-8  1.60µs ± 5%  1.53µs ± 5%  -4.04%  (p=0.000 n=15+14)
AppendInPlace/NoGrow/3Ptr-8  2.04µs ± 3%  1.96µs ± 2%  -3.90%  (p=0.000 n=13+14)
AppendInPlace/NoGrow/4Ptr-8  2.83µs ± 8%  2.62µs ± 4%  -7.39%  (p=0.000 n=13+15)

Previously these were 20% regressions.

Change-Id: Ie87810bffd598730658e07585f5e2ef979a12b8f
Reviewed-on: https://go-review.googlesource.com/22248Reviewed-by: Keith Randall <khr@golang.org>

Previously, isStaticCompositeLiteral would
return the wrong value for literals like:

[1]struct{ b []byte }{b: []byte{1}}

Note that the outermost component is an array,
but once we recurse into isStaticCompositeLiteral,
we never check again that arrays are actually arrays.

Instead of adding more logic to the guts of
isStaticCompositeLiteral, allow it to accept
any Node and return the correct answer.

Change-Id: I6af7814a9037bbc7043da9a96137fbee067bbe0e
Reviewed-on: https://go-review.googlesource.com/22247Reviewed-by: Keith Randall <khr@golang.org>

Per the latest spec refinement (https://golang.org/cl/19981).

Fixes #14537.

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

There is currently only one assembly implementation of AES
(amd64). While it is possible to fit other implementations to the
same pattern it complicates the code. For example s390x does not
use expanded keys, so having enc and dec in the aesCipher struct
is confusing.

By separating out the asm implementations we can more closely
match the data structures to the underlying implementation. This
also opens the door for AES implementations that support block
cipher modes other than GCM (e.g. CTR and CBC).

This commit changes BenchmarkExpandKey to test the go
implementation of key expansion. It might be better to have some
sort of 'initialisation' benchmark instead to cover the startup
costs of the assembly implementations (which might be doing
key expansion in a different way, or not at all).

Change-Id: I094a7176b5bbe2177df73163a9c0b711a61c12d6
Reviewed-on: https://go-review.googlesource.com/22193
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 21891 was too clever in its attempts to avoid spills.
Storing newlen too early caused uses of append in the runtime
itself to receive an inconsistent view of a slice,
leading to corruption.

This CL makes the generate code much more similar to
the old backend. It spills more than before,
but those spills have been contained to the grow path.
It recalculates newlen unnecessarily on the fast path,
but that's measurably cheaper than spilling it.

CL 21891 caused runtime failures in 6 of 2000 runs
of net/http and crypto/x509 in my test setup.
This CL has gone 6000 runs without a failure.


Benchmarks going from master to this CL:

name                         old time/op  new time/op  delta
AppendInPlace/NoGrow/Byte-8   439ns ± 2%   436ns ± 2%  -0.72%  (p=0.001 n=28+27)
AppendInPlace/NoGrow/1Ptr-8   901ns ± 0%   856ns ± 0%  -4.95%  (p=0.000 n=26+29)
AppendInPlace/NoGrow/2Ptr-8  2.15µs ± 1%  1.95µs ± 0%  -9.07%  (p=0.000 n=28+30)
AppendInPlace/NoGrow/3Ptr-8  2.66µs ± 0%  2.45µs ± 0%  -7.93%  (p=0.000 n=29+26)
AppendInPlace/NoGrow/4Ptr-8  3.24µs ± 1%  3.02µs ± 1%  -6.75%  (p=0.000 n=28+30)
AppendInPlace/Grow/Byte-8     269ns ± 1%   271ns ± 1%  +0.84%  (p=0.000 n=30+29)
AppendInPlace/Grow/1Ptr-8     275ns ± 1%   280ns ± 1%  +1.75%  (p=0.000 n=30+30)
AppendInPlace/Grow/2Ptr-8     384ns ± 0%   391ns ± 0%  +1.94%  (p=0.000 n=27+30)
AppendInPlace/Grow/3Ptr-8     455ns ± 0%   462ns ± 0%  +1.43%  (p=0.000 n=29+29)
AppendInPlace/Grow/4Ptr-8     478ns ± 0%   479ns ± 0%  +0.23%  (p=0.000 n=30+27)


However, for the large no-grow cases, there is still more work to be done.
Going from this CL to the non-SSA backend:

name                         old time/op  new time/op  delta
AppendInPlace/NoGrow/Byte-8   436ns ± 2%   436ns ± 2%     ~     (p=0.967 n=27+29)
AppendInPlace/NoGrow/1Ptr-8   856ns ± 0%   884ns ± 0%   +3.28%  (p=0.000 n=29+26)
AppendInPlace/NoGrow/2Ptr-8  1.95µs ± 0%  1.56µs ± 0%  -20.28%  (p=0.000 n=30+29)
AppendInPlace/NoGrow/3Ptr-8  2.45µs ± 0%  1.89µs ± 0%  -22.88%  (p=0.000 n=26+28)
AppendInPlace/NoGrow/4Ptr-8  3.02µs ± 1%  2.56µs ± 1%  -15.35%  (p=0.000 n=30+28)
AppendInPlace/Grow/Byte-8     271ns ± 1%   283ns ± 1%   +4.56%  (p=0.000 n=29+29)
AppendInPlace/Grow/1Ptr-8     280ns ± 1%   288ns ± 1%   +2.99%  (p=0.000 n=30+30)
AppendInPlace/Grow/2Ptr-8     391ns ± 0%   409ns ± 0%   +4.66%  (p=0.000 n=30+29)
AppendInPlace/Grow/3Ptr-8     462ns ± 0%   481ns ± 0%   +4.13%  (p=0.000 n=29+30)
AppendInPlace/Grow/4Ptr-8     479ns ± 0%   502ns ± 0%   +4.81%  (p=0.000 n=27+26)


New generated code:

var x []byte

func a() {
	x = append(x, 1)
}


"".a t=1 size=208 args=0x0 locals=0x48
	0x0000 00000 (a.go:5)	TEXT	"".a(SB), $72-0
	0x0000 00000 (a.go:5)	MOVQ	(TLS), CX
	0x0009 00009 (a.go:5)	CMPQ	SP, 16(CX)
	0x000d 00013 (a.go:5)	JLS	190
	0x0013 00019 (a.go:5)	SUBQ	$72, SP
	0x0017 00023 (a.go:5)	FUNCDATA	$0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0017 00023 (a.go:5)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0017 00023 (a.go:6)	MOVQ	"".x+16(SB), CX
	0x001e 00030 (a.go:6)	MOVQ	"".x+8(SB), DX
	0x0025 00037 (a.go:6)	MOVQ	"".x(SB), BX
	0x002c 00044 (a.go:6)	LEAQ	1(DX), BP
	0x0030 00048 (a.go:6)	CMPQ	BP, CX
	0x0033 00051 (a.go:6)	JGT	$0, 73
	0x0035 00053 (a.go:6)	LEAQ	1(DX), AX
	0x0039 00057 (a.go:6)	MOVQ	AX, "".x+8(SB)
	0x0040 00064 (a.go:6)	MOVB	$1, (BX)(DX*1)
	0x0044 00068 (a.go:7)	ADDQ	$72, SP
	0x0048 00072 (a.go:7)	RET
	0x0049 00073 (a.go:6)	LEAQ	type.[]uint8(SB), AX
	0x0050 00080 (a.go:6)	MOVQ	AX, (SP)
	0x0054 00084 (a.go:6)	MOVQ	BX, 8(SP)
	0x0059 00089 (a.go:6)	MOVQ	DX, 16(SP)
	0x005e 00094 (a.go:6)	MOVQ	CX, 24(SP)
	0x0063 00099 (a.go:6)	MOVQ	BP, 32(SP)
	0x0068 00104 (a.go:6)	PCDATA	$0, $0
	0x0068 00104 (a.go:6)	CALL	runtime.growslice(SB)
	0x006d 00109 (a.go:6)	MOVQ	40(SP), CX
	0x0072 00114 (a.go:6)	MOVQ	48(SP), DX
	0x0077 00119 (a.go:6)	MOVQ	DX, "".autotmp_0+64(SP)
	0x007c 00124 (a.go:6)	MOVQ	56(SP), BX
	0x0081 00129 (a.go:6)	MOVQ	BX, "".x+16(SB)
	0x0088 00136 (a.go:6)	MOVL	runtime.writeBarrier(SB), AX
	0x008e 00142 (a.go:6)	TESTB	AL, AL
	0x0090 00144 (a.go:6)	JNE	$0, 162
	0x0092 00146 (a.go:6)	MOVQ	CX, "".x(SB)
	0x0099 00153 (a.go:6)	MOVQ	"".x(SB), BX
	0x00a0 00160 (a.go:6)	JMP	53
	0x00a2 00162 (a.go:6)	LEAQ	"".x(SB), BX
	0x00a9 00169 (a.go:6)	MOVQ	BX, (SP)
	0x00ad 00173 (a.go:6)	MOVQ	CX, 8(SP)
	0x00b2 00178 (a.go:6)	PCDATA	$0, $0
	0x00b2 00178 (a.go:6)	CALL	runtime.writebarrierptr(SB)
	0x00b7 00183 (a.go:6)	MOVQ	"".autotmp_0+64(SP), DX
	0x00bc 00188 (a.go:6)	JMP	153
	0x00be 00190 (a.go:6)	NOP
	0x00be 00190 (a.go:5)	CALL	runtime.morestack_noctxt(SB)
	0x00c3 00195 (a.go:5)	JMP	0


Fixes #14969 again

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

Per a suggestion from mdempsky.

Both gc and gccgo consider a statement list as terminating if the
last _non_empty_ statement is terminating; i.e., trailing semis are
ok. Only gotype followed the current stricter rule in the spec.

This change adjusts the spec to match gc and gccgo behavior. In
support of this change, the spec has a matching rule for fallthrough,
which in valid positions may be followed by trailing semis as well.

For details and examples, see the issue below.

Fixes #14422.

Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade
Reviewed-on: https://go-review.googlesource.com/19981Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The encryptBlock and decryptBlock functions are already tested
(via the public API) by TestCipherEncrypt and TestCipherDecrypt
respectively. Both sets of tests check the output of the two
functions against the same set of FIPS 197 examples. I therefore
think it is safe to delete these two tests without losing any
coverage.

Deleting these two tests will make it easier to modify the
internal API, which I am hoping to do in future CLs.

Change-Id: I0dd568bc19f47b70ab09699b507833e527d39ba7
Reviewed-on: https://go-review.googlesource.com/22115Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This change adds Zone field to IPNet structure for making it possible to
determine which network interface is associated with IPv6 link-local
address. Also makes ParseCIDR and IPNet.String capable handling literal
IPv6 address prefixes with zone identifier.

Fixes #14518.

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

Go 1.6 requires Windows XP or later. I have:

C:\>systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
OS Name:                   Microsoft Windows XP Professional
OS Version:                5.1.2600 Service Pack 3 Build 2600

Running "go test" PASSes on my system after this CL is applied.

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

DualStack mode requires dialTCP to support cancellation,
which has been implemented for Plan 9 in CL 22144.

Updates #11225.
Updates #11932.

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

TestDialParallel, TestDialerFallbackDelay and TestDialCancel
require dialTCP to support cancellation, which has been
implemented for Plan 9 in CL 22144.

Updates #11225.
Updates #11932.

Change-Id: I3b30a645ef79227dfa519cde8d46c67b72f2485c
Reviewed-on: https://go-review.googlesource.com/22203
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Per feedback from mdempsky from https://go-review.googlesource.com/22096.

Also fix emitted position info.

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

On Plan 9, when closing a TCP connection, we
write the "hangup" string to the TCP ctl file.

The next read on the TCP data file will return
an error like "/net/tcp/18/data: Hangup", while
in Go, we expect to return io.EOF.

This change makes Read to return io.EOF when
an error string containing "Hangup" is returned.

Change-Id: I3f71ed543704190b441cac4787488a77f46d88a1
Reviewed-on: https://go-review.googlesource.com/22149Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use (part of) a SHA-1 checksum to replace type symbol names.

In typical programs this has no effect because types are not included
in the symbol table. But when dynamically linking, types are in the
table to make sure there is only one *rtype per Go type.

Eventually we may be able to get rid of all pointers to rtype values in
the binary, but probably not by 1.7. And this has a nice effect on
binary size today:

libstd.so:
	before 27.4MB
	after  26.2MB

For #6853.

Change-Id: I603d7f3e5baad84f59f2fd37eeb1e4ae5acfe44a
Reviewed-on: https://go-review.googlesource.com/21583Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Some rewrites to simplify logical operations.

Fixes #14363

Change-Id: I45a1e8f227267cbcca0778101125f7bab776a5dd
Reviewed-on: https://go-review.googlesource.com/22188Reviewed-by: Alexandru Moșoi <alexandru@mosoi.ro>
Run-TryBot: Alexandru Moșoi <alexandru@mosoi.ro>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Instead of writing out the type almost twice in the symbol name,
teach the linker how to sort typelink symbols by their contents.

This ~halves the size of typelink symbol names, which helps very
large (6KB) names like those mentioned in #15104.

This does not increase the total sorting work done by the linker,
and makes it possible to use shorter symbol names for types. See
the follow-on CL 21583.

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

Bug fix went in CL 21396, this is a matching test.

Fixes #15343

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

Change-Id: I2b43cc976d2efbf8b41170be536fdd10364b65e5
Reviewed-on: https://go-review.googlesource.com/22190Reviewed-by: Keith Randall <khr@golang.org>

*p = [5]byte{1,2,3,4,5}

First we allocate a global containing the RHS.  Then we copy
that global to a local stack variable, and then copy that local
stack variable to *p.  The intermediate copy is unnecessary.

Note that this only works if the RHS is completely constant.
If the code was:
*p = [5]byte{1,2,x,4,5}
this optimization doesn't apply as we have to construct the
RHS on the stack before copying it to *p.

Fixes #12841

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

My previous https://golang.org/cl/22101 to add context throughout the
net package broke Plan 9, which isn't currently tested (#15251).

It also broke some old unsupported version of Windows (Windows 2000?)
which doesn't have the ConnectEx function, but that was only found
visually, since our minimum supported Windows version has ConnectEx.
This change simplifies the Windows and deletes the non-ConnectEx code
path.  Windows 2000 will work even less now, if it even worked
before. Windows XP remains our minimum supported version.

Specifically, the previous CL stopped using the "dial" function, which
0intro noted:
https://github.com/golang/go/issues/15333#issuecomment-210842761

This CL removes the dial function instead and makes plan9's net
implementation respect contexts, which likely fixes a number of
t.Skipped tests. I'm leaving that to 0intro to investigate.

In the process of propagating and respecting contexts for plan9, I had
to change some signatures to add contexts to more places and ended up
pushing contexts down into the Go-based DNS resolution as well,
replacing the pure-Go DNS implementation's use of "timeout
time.Duration" with a context instead.

Updates #11932
Updates #15328

Fixes #15333

Change-Id: I6ad1e62f38271cdd86b3f40921f2d0f23374936a
Reviewed-on: https://go-review.googlesource.com/22144Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The GNU linker follows the letter of -znocopyreloc by refusing to
generate COPY relocations on arm64. Unfortunately it generates an
error instead of finding another way. The gold linker works, so
switch to it.

Fixes linux/arm64 build.

Change-Id: I1f7119d999c8f9f1f2d0c1e06b6462cea9c02a71
Reviewed-on: https://go-review.googlesource.com/22185
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #15312

Change-Id: I4fabef3f21081bc4b020069851b5c2504bc6b4d8
Reviewed-on: https://go-review.googlesource.com/22122Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Passes toolstash -cmp.

Fixes #15311.

Change-Id: I1d67f5c9de38e899ab2d6c8986fabd6f197df23a
Reviewed-on: https://go-review.googlesource.com/22162Reviewed-by: David Crawshaw <crawshaw@golang.org>

Introduce and start using nameOff for two encoded names. This pair
of changes is best done together because the linker's method decoder
expects the method layouts to match.

Precursor to converting all existing name and *string fields to
nameOff.

linux/amd64:
	cmd/go:  -45KB (0.5%)
	jujud:  -389KB (0.6%)

linux/amd64 PIE:
	cmd/go: -170KB (1.4%)
	jujud:  -1.5MB (1.8%)

For #6853.

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

On ARM, use the gold linker to avoid copy relocations.
https://sourceware.org/bugzilla/show_bug.cgi?id=19962

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

Fixes #15315

Change-Id: I8fea31507a5f83df8a86fb067f1b11d90133dc09
Reviewed-on: https://go-review.googlesource.com/22180Reviewed-by: Chris Broadfoot <cbro@golang.org>

This adds size calculation to "dynamic" writes.
This ensures that if dynamic Huffman encoding is bigger,
or only slightly smaller than raw data, the block is written
uncompressed.

To minimize the code duplication of this function, the
size calculation has been moved to separate functions.

Since I was modifying these calculations, I changed "int64"
size calculations to "int". Blocks are of very limited size,
so there is not any risk of overflows.
This should mainly improve 32 bit performance, but amd64 also
gets a slight boost:

name                       old time/op    new time/op    delta
EncodeDigitsHuffman1e4-8     49.9µs ± 1%    49.3µs ± 1%  -1.21%  (p=0.000 n=10+10)
EncodeDigitsHuffman1e5-8      476µs ± 1%     471µs ± 3%    ~     (p=0.218 n=10+10)
EncodeDigitsHuffman1e6-8     4.80ms ± 2%    4.75ms ± 2%    ~      (p=0.243 n=10+9)
EncodeDigitsSpeed1e4-8        305µs ± 3%     300µs ± 1%  -1.86%  (p=0.005 n=10+10)
EncodeDigitsSpeed1e5-8       3.67ms ± 2%    3.58ms ± 1%  -2.29%    (p=0.000 n=9+8)
EncodeDigitsSpeed1e6-8       38.3ms ± 2%    37.0ms ± 1%  -3.45%    (p=0.000 n=9+9)
EncodeDigitsDefault1e4-8      361µs ± 2%     353µs ± 1%  -2.21%  (p=0.000 n=10+10)
EncodeDigitsDefault1e5-8     5.24ms ± 2%    5.19ms ± 2%    ~     (p=0.105 n=10+10)
EncodeDigitsDefault1e6-8     56.5ms ± 3%    55.1ms ± 1%  -2.42%  (p=0.001 n=10+10)
EncodeDigitsCompress1e4-8     362µs ± 2%     358µs ± 2%    ~     (p=0.123 n=10+10)
EncodeDigitsCompress1e5-8    5.26ms ± 3%    5.20ms ± 1%    ~     (p=0.089 n=10+10)
EncodeDigitsCompress1e6-8    56.0ms ± 4%    55.0ms ± 1%    ~      (p=0.065 n=10+9)
EncodeTwainHuffman1e4-8      70.9µs ± 3%    67.6µs ± 2%  -4.59%  (p=0.000 n=10+10)
EncodeTwainHuffman1e5-8       556µs ± 2%     533µs ± 1%  -4.20%  (p=0.000 n=10+10)
EncodeTwainHuffman1e6-8      5.54ms ± 3%    5.29ms ± 1%  -4.37%   (p=0.000 n=10+9)
EncodeTwainSpeed1e4-8         294µs ± 3%     293µs ± 1%    ~      (p=0.965 n=10+8)
EncodeTwainSpeed1e5-8        2.59ms ± 2%    2.56ms ± 1%    ~     (p=0.353 n=10+10)
EncodeTwainSpeed1e6-8        25.6ms ± 1%    24.9ms ± 1%  -2.62%   (p=0.000 n=9+10)
EncodeTwainDefault1e4-8       419µs ± 2%     417µs ± 1%    ~      (p=0.780 n=10+9)
EncodeTwainDefault1e5-8      6.23ms ± 4%    6.16ms ± 1%    ~     (p=0.218 n=10+10)
EncodeTwainDefault1e6-8      66.2ms ± 2%    65.7ms ± 1%    ~     (p=0.529 n=10+10)
EncodeTwainCompress1e4-8      426µs ± 1%     428µs ± 2%    ~      (p=0.549 n=9+10)
EncodeTwainCompress1e5-8     6.80ms ± 1%    6.85ms ± 3%    ~      (p=0.156 n=9+10)
EncodeTwainCompress1e6-8     74.6ms ± 3%    73.8ms ± 2%    ~     (p=0.280 n=10+10)

name                       old speed      new speed      delta
EncodeDigitsHuffman1e4-8    200MB/s ± 1%   203MB/s ± 1%  +1.23%  (p=0.000 n=10+10)
EncodeDigitsHuffman1e5-8    210MB/s ± 1%   212MB/s ± 3%    ~      (p=0.356 n=10+9)
EncodeDigitsHuffman1e6-8    208MB/s ± 2%   210MB/s ± 2%    ~      (p=0.243 n=10+9)
EncodeDigitsSpeed1e4-8     32.8MB/s ± 3%  33.4MB/s ± 1%  +1.88%  (p=0.005 n=10+10)
EncodeDigitsSpeed1e5-8     27.2MB/s ± 2%  27.9MB/s ± 1%  +2.60%   (p=0.000 n=10+8)
EncodeDigitsSpeed1e6-8     26.1MB/s ± 2%  27.0MB/s ± 1%  +3.56%    (p=0.000 n=9+9)
EncodeDigitsDefault1e4-8   27.7MB/s ± 2%  28.4MB/s ± 1%  +2.24%  (p=0.000 n=10+10)
EncodeDigitsDefault1e5-8   19.1MB/s ± 2%  19.3MB/s ± 2%    ~     (p=0.101 n=10+10)
EncodeDigitsDefault1e6-8   17.7MB/s ± 3%  18.1MB/s ± 1%  +2.46%  (p=0.001 n=10+10)
EncodeDigitsCompress1e4-8  27.6MB/s ± 2%  27.9MB/s ± 2%    ~     (p=0.119 n=10+10)
EncodeDigitsCompress1e5-8  19.0MB/s ± 3%  19.2MB/s ± 1%    ~     (p=0.085 n=10+10)
EncodeDigitsCompress1e6-8  17.9MB/s ± 4%  18.1MB/s ± 3%    ~     (p=0.110 n=10+10)
EncodeTwainHuffman1e4-8     141MB/s ± 3%   148MB/s ± 2%  +4.79%  (p=0.000 n=10+10)
EncodeTwainHuffman1e5-8     180MB/s ± 2%   188MB/s ± 1%  +4.38%  (p=0.000 n=10+10)
EncodeTwainHuffman1e6-8     181MB/s ± 3%   189MB/s ± 1%  +4.54%   (p=0.000 n=10+9)
EncodeTwainSpeed1e4-8      34.0MB/s ± 3%  34.1MB/s ± 1%    ~      (p=0.948 n=10+8)
EncodeTwainSpeed1e5-8      38.7MB/s ± 2%  39.0MB/s ± 1%    ~     (p=0.353 n=10+10)
EncodeTwainSpeed1e6-8      39.1MB/s ± 1%  40.1MB/s ± 1%  +2.68%   (p=0.000 n=9+10)
EncodeTwainDefault1e4-8    23.9MB/s ± 2%  24.0MB/s ± 1%    ~      (p=0.734 n=10+9)
EncodeTwainDefault1e5-8    16.0MB/s ± 4%  16.2MB/s ± 1%    ~     (p=0.210 n=10+10)
EncodeTwainDefault1e6-8    15.1MB/s ± 2%  15.2MB/s ± 1%    ~     (p=0.515 n=10+10)
EncodeTwainCompress1e4-8   23.5MB/s ± 1%  23.4MB/s ± 2%    ~      (p=0.536 n=9+10)
EncodeTwainCompress1e5-8   14.7MB/s ± 1%  14.6MB/s ± 3%    ~      (p=0.138 n=9+10)
EncodeTwainCompress1e6-8   13.4MB/s ± 3%  13.5MB/s ± 2%    ~     (p=0.239 n=10+10)

This improves "random input" to the dynamic writer, which is why the test data is
updated. The output size goes from 1051 to 1005 bytes.

Change-Id: I3ee11d2d2511b277d2dd16734aeea07c98bca450
Reviewed-on: https://go-review.googlesource.com/21757Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>

Updates #15292.

Change-Id: I229f66c2a41ae0738225f2ba7a574478f5d6d620
Reviewed-on: https://go-review.googlesource.com/22163Reviewed-by: Andrew Gerrand <adg@golang.org>

We no longer use yacc, and we shouldn't have any y.output files.

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

Fixes #15339

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

Ignore the f.zero flag and use spaces for padding instead
when precision is set.

Fixes #15331

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

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

It’d be nicer to write just

_ = dpix[x+3]

but the compiler isn’t able to reason about offsets
from symbols (yet).

image/draw benchmark:

YCbCr-8   722µs ± 3%   682µs ± 3%  -5.54%  (p=0.000 n=50+50)

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

They have different semantics.

Equal is stricter and is designed for the front-end.
Compare is looser and cheaper and is designed for the back-end.
To avoid possible regression, remove Equal from ssa.Type.

Updates #15043

Change-Id: Ie23ce75ff6b4d01b7982e0a89e6f81b5d099d8d6
Reviewed-on: https://go-review.googlesource.com/21483Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>

In JSON terminology, "object" is a collect of key/value pairs. But a
JSON object is only one type of JSON value (others are string, number,
array, true, false, null).

This updates the Go docs (at least the public godoc) to not use
"object" when we mean any JSON value.

Change-Id: Ieb1c456c703693714d63d9d09d306f4d9e8f4597
Reviewed-on: https://go-review.googlesource.com/22003Reviewed-by: Andrew Gerrand <adg@golang.org>

Currently the scavenger marks memory unused in multiples of the
allocator page size (8K). This is safe as long as the true physical
page size is 4K (or 8K), as it is on many platforms. However, on
ARM64, PPC64x, and MIPS64, the physical page size is larger than 8K,
so if we attempt to mark memory unused, the kernel will round the
boundaries of the region *out* to all pages covered by the requested
region, and we'll release a larger region of memory than intended. As
a result, the scavenger is currently disabled on these platforms.

Fix this by first rounding the region to be marked unused *in* to
multiples of the physical page size, so that when we ask the kernel to
mark it unused, it releases exactly the requested region.

Fixes #9993.

Change-Id: I96d5fdc2f77f9d69abadcea29bcfe55e68288cb1
Reviewed-on: https://go-review.googlesource.com/22066Reviewed-by: Rick Hudson <rlh@golang.org>

If sysUnused is passed an address or length that is not aligned to the
physical page boundary, the kernel will unmap more memory than the
caller wanted. Add a check for this.

For #9993.

Change-Id: I68ff03032e7b65cf0a853fe706ce21dc7f2aaaf8
Reviewed-on: https://go-review.googlesource.com/22065Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

The runtime hard-codes an assumed physical page size. If this is
smaller than the kernel's page size or not a multiple of it, sysUnused
may incorrectly release more memory to the system than intended.

Add a runtime startup check that the runtime's assumed physical page
is compatible with the kernel's physical page size.

For #9993.

Change-Id: Ida9d07f93c00ca9a95dd55fc59bf0d8a607f6728
Reviewed-on: https://go-review.googlesource.com/22064Reviewed-by: Rick Hudson <rlh@golang.org>

archauxv no longer does anything on 386, so remove it.

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