While writing CL 107315, I went back and forth for the syntax used for
constraints of build environments in which the architecture did not
support varitants ("plan9/amd64" vs "plan9/amd64/"). I eventually
settled for the latter because the code required less heuristics
(think parsing "plan9/386" vs "386/sse2") but there were a few
leftovers in code and comments.

Change-Id: I9d9a008f3814f9a1642609650eb571e7f1a675cf
Reviewed-on: https://go-review.googlesource.com/107338
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Not used anymore, all tests have been migrated to
the top-level testsuite.

Change-Id: I536e6c14f62153c01e4966ad41e1501b38494c7f
Reviewed-on: https://go-review.googlesource.com/107336
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

After CL 104636 cpu.X86.HasAVX is set early enough that it can be used
in runtime·memclrNoHeapPointers. Add an offset to use in assembly and
replace the only occurence of support_avx2.

Change-Id: Icada62efeb3e24d71251d55623a8a8602364c9a8
Reviewed-on: https://go-review.googlesource.com/106595
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>

This CL makes the codegen testsuite automatically test all
architecture variants for architecture specified in tests. For
instance, if a test file specifies a "arm" test, it will be
automatically run on all GOARM variants (5,6,7), to increase
the coverage.

The CL also introduces a syntax to specify only a specific
variant (eg: "arm/7") in case the test makes sense only there.
The same syntax also allows to specify the operating system
in case it matters (eg: "plan9/386/sse2").

Fixes #24658

Change-Id: I2eba8b918f51bb6a77a8431a309f8b71af07ea22
Reviewed-on: https://go-review.googlesource.com/107315
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

And remove it from asmtest. Next CL will remove the whole
asmtest infrastructure.

Change-Id: I5851bf7c617456d62a3c6cffacf70252df7b056b
Reviewed-on: https://go-review.googlesource.com/107335
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 106463 introduced what seems to trim the "go:" prefix in pramas
comments twice, so "//go:go:foo" would be handled, too.
So either the strings.TrimPrefix or the [3:]-slicing is not needed.

I opted to remove the [3:]-slicing.

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

Fixes gosimple warning "if err != nil { return err };
return nil' can be simplified to 'return err"

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

It was skipping dirs starting with ".", but it was missing the "_"
prefix and the "testdata" name. From "go help packages":

	Directory and file names that begin with "." or "_" are ignored
	by the go tool, as are directories named "testdata".

Before the change:

	$ go doc z # using src/cmd/go/testdata/testvendor/src/q/z
	package z // import "."

After the fix, it falls back to the current directory, as expected when
a single argument isn't found as a package in $GOPATH.

TestMain needs a small adjustment to keep the tests working, as now
their use of cmd/doc/testdata would normally not work.

Fixes #24462.

Change-Id: I1f5d6d1eba0fb59aff55db33b3b1147e300284ef
Reviewed-on: https://go-review.googlesource.com/106935
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

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

The tabwriter tracks cells on a line-by-line basis.
This can be memory-hungry when working with large input.

This change adds two optimizations.

First, when there's an existing cell slice for a line,
don't overwrite it by appending.
This helps when re-using a Writer,
or when the output is broken into groups,
e.g. by a blank line.
We now re-use that existing cell slice.

Second, we predict that the number of cells in a line
will probably match those of the previous line,
since tabwriter is most often used to format tables.

This has a noticeable impact on cmd/objdump (#24725).
It reduces allocated space by about 55%.
It also speeds it up some.
Using "benchcmd -n 10 Objdump go tool objdump `which go`":

name            old time/op       new time/op       delta
ObjdumpCompile        9.03s ± 1%        8.51s ± 1%  -5.81%  (p=0.000 n=10+10)

It might also imaginably speed up gofmt on some
large machine-generated code.

name                old time/op    new time/op    delta
Table/1x10/new-8            2.89µs ± 1%    2.39µs ± 1%   -17.39%  (p=0.000 n=13+14)
Table/1x10/reuse-8          2.13µs ± 1%    1.29µs ± 2%   -39.58%  (p=0.000 n=14+15)
Table/1x1000/new-8           203µs ± 0%     147µs ± 1%   -27.45%  (p=0.000 n=13+14)
Table/1x1000/reuse-8         194µs ± 1%     113µs ± 2%   -42.01%  (p=0.000 n=14+15)
Table/1x100000/new-8        33.1ms ± 1%    27.5ms ± 2%   -17.08%  (p=0.000 n=15+15)
Table/1x100000/reuse-8      22.0ms ± 3%    11.8ms ± 1%   -46.23%  (p=0.000 n=14+12)
Table/10x10/new-8           8.51µs ± 0%    6.52µs ± 1%   -23.48%  (p=0.000 n=13+15)
Table/10x10/reuse-8         7.41µs ± 0%    4.59µs ± 3%   -38.03%  (p=0.000 n=14+15)
Table/10x1000/new-8          749µs ± 0%     521µs ± 1%   -30.39%  (p=0.000 n=12+15)
Table/10x1000/reuse-8        732µs ± 1%     448µs ± 2%   -38.79%  (p=0.000 n=15+14)
Table/10x100000/new-8        102ms ± 2%      74ms ± 2%   -28.05%  (p=0.000 n=14+15)
Table/10x100000/reuse-8     96.2ms ± 4%    55.4ms ± 3%   -42.36%  (p=0.000 n=15+15)
Table/100x10/new-8          50.3µs ± 1%    43.3µs ± 1%   -13.87%  (p=0.000 n=14+15)
Table/100x10/reuse-8        47.6µs ± 1%    36.1µs ± 1%   -24.09%  (p=0.000 n=14+14)
Table/100x1000/new-8        5.17ms ± 1%    4.11ms ± 1%   -20.40%  (p=0.000 n=14+13)
Table/100x1000/reuse-8      5.00ms ± 1%    3.73ms ± 1%   -25.46%  (p=0.000 n=14+14)
Table/100x100000/new-8       654ms ± 2%     531ms ± 2%   -18.86%  (p=0.000 n=13+14)
Table/100x100000/reuse-8     709ms ± 1%     505ms ± 2%   -28.77%  (p=0.000 n=12+15)
Pyramid/10-8                4.22µs ± 1%    4.21µs ± 1%      ~     (p=0.067 n=14+14)
Pyramid/100-8                378µs ± 0%     378µs ± 0%    +0.17%  (p=0.022 n=13+13)
Pyramid/1000-8               133ms ± 3%     132ms ± 3%      ~     (p=0.148 n=15+15)
Ragged/10-8                 6.10µs ± 0%    5.16µs ± 0%   -15.38%  (p=0.000 n=14+15)
Ragged/100-8                54.5µs ± 0%    43.8µs ± 0%   -19.59%  (p=0.000 n=14+15)
Ragged/1000-8                532µs ± 0%     424µs ± 0%   -20.25%  (p=0.000 n=14+14)

name                old alloc/op   new alloc/op   delta
Table/1x10/new-8            1.76kB ± 0%    1.52kB ± 0%   -13.64%  (p=0.000 n=15+15)
Table/1x10/reuse-8            800B ± 0%        0B       -100.00%  (p=0.000 n=15+15)
Table/1x1000/new-8           131kB ± 0%      99kB ± 0%   -24.30%  (p=0.000 n=15+15)
Table/1x1000/reuse-8        80.0kB ± 0%     0.0kB ± 0%   -99.99%  (p=0.000 n=15+15)
Table/1x100000/new-8        23.1MB ± 0%    19.9MB ± 0%   -13.85%  (p=0.000 n=15+15)
Table/1x100000/reuse-8      8.30MB ± 0%    0.20MB ± 0%   -97.60%  (p=0.000 n=13+12)
Table/10x10/new-8           8.94kB ± 0%    5.06kB ± 0%   -43.47%  (p=0.000 n=15+15)
Table/10x10/reuse-8         7.52kB ± 0%    0.00kB       -100.00%  (p=0.000 n=15+15)
Table/10x1000/new-8          850kB ± 0%     387kB ± 0%   -54.50%  (p=0.000 n=13+15)
Table/10x1000/reuse-8        752kB ± 0%       0kB ± 0%   -99.98%  (p=0.000 n=13+15)
Table/10x100000/new-8       95.7MB ± 0%    49.3MB ± 0%   -48.50%  (p=0.000 n=14+15)
Table/10x100000/reuse-8     76.2MB ± 0%     2.5MB ± 0%   -96.77%  (p=0.000 n=13+15)
Table/100x10/new-8          66.3kB ± 0%    38.0kB ± 0%   -42.65%  (p=0.000 n=15+15)
Table/100x10/reuse-8        61.3kB ± 0%     0.0kB       -100.00%  (p=0.000 n=15+15)
Table/100x1000/new-8        6.69MB ± 0%    3.25MB ± 0%   -51.37%  (p=0.000 n=15+15)
Table/100x1000/reuse-8      6.13MB ± 0%    0.01MB ± 0%   -99.89%  (p=0.000 n=15+15)
Table/100x100000/new-8       684MB ± 0%     340MB ± 0%   -50.29%  (p=0.000 n=14+15)
Table/100x100000/reuse-8     648MB ± 0%     170MB ± 0%   -73.78%  (p=0.000 n=14+13)
Pyramid/10-8                4.40kB ± 0%    4.40kB ± 0%      ~     (all equal)
Pyramid/100-8                652kB ± 0%     652kB ± 0%      ~     (p=0.715 n=15+15)
Pyramid/1000-8              96.7MB ± 0%    96.7MB ± 0%      ~     (p=0.084 n=15+14)
Ragged/10-8                 5.17kB ± 0%    4.51kB ± 0%   -12.69%  (p=0.000 n=15+15)
Ragged/100-8                50.2kB ± 0%    41.1kB ± 0%   -18.04%  (p=0.000 n=15+15)
Ragged/1000-8                492kB ± 0%     401kB ± 0%   -18.61%  (p=0.000 n=15+15)

name                old allocs/op  new allocs/op  delta
Table/1x10/new-8              29.0 ± 0%      21.0 ± 0%   -27.59%  (p=0.000 n=15+15)
Table/1x10/reuse-8            20.0 ± 0%       0.0       -100.00%  (p=0.000 n=15+15)
Table/1x1000/new-8           2.02k ± 0%     1.02k ± 0%   -49.38%  (p=0.000 n=15+15)
Table/1x1000/reuse-8         2.00k ± 0%     0.00k       -100.00%  (p=0.000 n=15+15)
Table/1x100000/new-8          200k ± 0%      100k ± 0%   -49.98%  (p=0.000 n=15+15)
Table/1x100000/reuse-8        200k ± 0%        1k ± 0%   -99.50%  (p=0.000 n=14+15)
Table/10x10/new-8             66.0 ± 0%      31.0 ± 0%   -53.03%  (p=0.000 n=15+15)
Table/10x10/reuse-8           50.0 ± 0%       0.0       -100.00%  (p=0.000 n=15+15)
Table/10x1000/new-8          5.03k ± 0%     1.04k ± 0%   -79.36%  (p=0.000 n=15+15)
Table/10x1000/reuse-8        5.00k ± 0%     0.00k       -100.00%  (p=0.000 n=15+15)
Table/10x100000/new-8         500k ± 0%      100k ± 0%   -79.99%  (p=0.000 n=15+15)
Table/10x100000/reuse-8       500k ± 0%        5k ± 0%   -99.00%  (p=0.000 n=15+15)
Table/100x10/new-8             102 ± 0%        40 ± 0%   -60.78%  (p=0.000 n=15+15)
Table/100x10/reuse-8          80.0 ± 0%       0.0       -100.00%  (p=0.000 n=15+15)
Table/100x1000/new-8         8.04k ± 0%     1.05k ± 0%   -86.91%  (p=0.000 n=15+15)
Table/100x1000/reuse-8       8.00k ± 0%     0.00k ± 0%   -99.98%  (p=0.000 n=15+15)
Table/100x100000/new-8        800k ± 0%      100k ± 0%   -87.49%  (p=0.000 n=15+12)
Table/100x100000/reuse-8      800k ± 0%       50k ± 0%   -93.74%  (p=0.000 n=14+13)
Pyramid/10-8                  20.0 ± 0%      20.0 ± 0%      ~     (all equal)
Pyramid/100-8                 50.0 ± 0%      50.0 ± 0%      ~     (all equal)
Pyramid/1000-8                 109 ± 0%       109 ± 0%      ~     (all equal)
Ragged/10-8                   54.0 ± 0%      34.0 ± 0%   -37.04%  (p=0.000 n=15+15)
Ragged/100-8                   422 ± 0%       188 ± 0%   -55.45%  (p=0.000 n=15+15)
Ragged/1000-8                4.03k ± 0%     1.66k ± 0%   -58.80%  (p=0.000 n=15+15)

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

There are two flakes present on the dashboard for this test.

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

RawRead assumes the callback will perform either (a) a blocking read
and always return true, (b) a blocking read with a SO_RCVTIMEO set
returning false on WSAETIMEDOUT, or (c) a non-blocking read
returning false on WSAEWOULDBLOCK. In the latter two cases, it uses
a 0-byte overlapped read for notifications from the IOCP runtime
when the socket becomes readable before trying again.

RawWrite assumes the callback will perform blocking write and will
always return true, and makes no effort to tie into the runtime loop.

Change-Id: Ib10074e9d502c040294f41a260e561e84208652f
Reviewed-on: https://go-review.googlesource.com/76391
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Windows process cannot run properly, if it only has
GOOS and GOARCH environment variables set. It needs
other environment variables. So adjust TestLarge and
TestNoRet to add GOOS and GOARCH to the existing
variables set instead of clearing environment.

Fixes #24855

Change-Id: I9fd9430d89031c3bacdbc6283450efaa4819e616
Reviewed-on: https://go-review.googlesource.com/107035
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 92475 added WSAEMSGSIZE const to syscall package. But there
is already copy of WSAEMSGSIZE in internal/syscall/windows.
So delete syscall.WSAEMSGSIZE

Change-Id: I0b81fa5dcf846887a0cb27d8bbd7e250860627b5
Reviewed-on: https://go-review.googlesource.com/106956
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Since the tabwriter is flushed at every symbol,
it can be re-used with no impact on the output.

This cuts allocated space when objdump-ing
the compiler by almost 40%,
and enables further upcoming improvements.

It also speeds up objdump.

name            old time/op       new time/op       delta
ObjdumpCompile        9.22s ± 3%        8.77s ± 3%   -4.79%  (p=0.000 n=10+9)

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

We sometimes generate code like this:

v473 = MOVQconst <uintptr> // constant..
v580 = MOVBstoreidx1 <mem> v1056 v473 v819 v491 // ..only used as an index

Rewrite indexed stores to non-indexed version, where possible.
This allows to eliminate  const->register move, reducing codesize and lowering register pressure.

Change-Id: Id5fed801dffe3f1a80876b8d8bd43775a7c942b2
Reviewed-on: https://go-review.googlesource.com/105295
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Add a special case for power-of-2 sized elements.
We can replace div/mul with left/right shift and avoid expensive operation.
growslice is hotter for short slices of small elements, such as int16, so
add an int16 version for GrowSlice benchmark.

name                   old time/op  new time/op  delta
GrowSlice/Byte-6       61.3ns ± 3%  60.5ns ± 4%  -1.33%  (p=0.002 n=30+30)
GrowSlice/Int16-6      94.0ns ± 4%  84.7ns ± 2%  -9.82%  (p=0.000 n=30+30)
GrowSlice/Int-6         100ns ± 1%    99ns ± 1%  -0.25%  (p=0.032 n=29+28)
GrowSlice/Ptr-6         197ns ± 2%   195ns ± 2%  -0.94%  (p=0.001 n=30+29)
GrowSlice/Struct/24-6   168ns ± 1%   166ns ± 2%  -1.09%  (p=0.000 n=25+30)
GrowSlice/Struct/32-6   187ns ± 2%   180ns ± 1%  -3.59%  (p=0.000 n=30+30)
GrowSlice/Struct/40-6   241ns ± 2%   238ns ± 2%  -1.41%  (p=0.000 n=30+30)

Change-Id: I31e8388d73fd9356e2dcc091d8d92eef3e3ccdbc
Reviewed-on: https://go-review.googlesource.com/102279
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

This commit adds the wasm architecture to the time package.

Updates #18892

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

runtime/traceback: support tracking goroutine ancestor tracebacks with GODEBUG="tracebackancestors=N"

Currently, collecting a stack trace via runtime.Stack captures the stack for the
immediately running goroutines. This change extends those tracebacks to include
the tracebacks of their ancestors. This is done with a low memory cost and only
utilized when debug option tracebackancestors is set to a value greater than 0.

Resolves #22289

Change-Id: I7edacc62b2ee3bd278600c4a21052c351f313f3a
Reviewed-on: https://go-review.googlesource.com/70993
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

This commit adds the wasm architecture to the mime package.

Updates #18892

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

This cuts the allocated space while executing

go tool objdump -S `go tool -n compile`

by over 10%.

It also speeds it up slightly:

name              old time/op       new time/op       delta
ObjdumpSCompiler        9.03s ± 1%        8.88s ± 1%  -1.59%  (p=0.000 n=20+20)

Updates #24725

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

On my system, this seems to be a significant win, with a major
reduction in allocations and minor speed improvement.

name           old time/op    new time/op    delta
CodeMarshal      9.75ms ± 3%    9.24ms ± 1%   -5.21%  (p=0.001 n=5+10)
CodeMarshal-4    4.98ms ± 1%    4.71ms ± 1%   -5.44%  (p=0.001 n=5+10)
CodeMarshal-8    4.80ms ± 0%    4.77ms ± 1%   -0.70%  (p=0.012 n=5+9)

name           old speed      new speed      delta
CodeMarshal     199MB/s ± 3%   210MB/s ± 1%   +5.46%  (p=0.001 n=5+10)
CodeMarshal-4   390MB/s ± 1%   412MB/s ± 1%   +5.76%  (p=0.001 n=5+10)
CodeMarshal-8   404MB/s ± 0%   407MB/s ± 1%   +0.70%  (p=0.012 n=5+9)

name           old alloc/op   new alloc/op   delta
CodeMarshal      4.59MB ± 0%    1.96MB ± 0%  -57.22%  (p=0.000 n=5+9)
CodeMarshal-4    4.59MB ± 0%    2.00MB ± 0%  -56.39%  (p=0.000 n=5+8)
CodeMarshal-8    4.59MB ± 0%    2.06MB ± 0%  -55.05%  (p=0.001 n=5+9)

name           old allocs/op  new allocs/op  delta
CodeMarshal        16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)
CodeMarshal-4      16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)
CodeMarshal-8      16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)

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

Fixes #24841
Updates #24845

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

Use the new softfloat support in the compiler, originally added
for softfloat on MIPS. This support is portable, so we can just
use it for softfloat on ARM.

In the old softfloat support on ARM, the compiler generates
floating point instructions, then the assembler inserts calls
to _sfloat before FP instructions. _sfloat decodes the following
FP instructions and simulates them.

In the new scheme, the compiler generates runtime calls to do FP
operations at a higher level. It doesn't generate FP instructions,
and therefore the assembler won't insert _sfloat calls, i.e. the
old mechanism is automatically suppressed.

The old method may be still be triggered with assembly code
using FP instructions. In the standard library, the only
occurance is math/sqrt_arm.s, which is rewritten to call to the
Go implementation instead.

Some significant speedups for code using floating points:

name                     old time/op    new time/op     delta
BinaryTree17-4              37.1s ± 2%      37.3s ± 1%     ~     (p=0.105 n=10+10)
Fannkuch11-4                13.0s ± 0%      13.1s ± 0%   +0.46%  (p=0.000 n=10+10)
FmtFprintfEmpty-4           700ns ± 4%      734ns ± 6%   +4.84%  (p=0.009 n=10+10)
FmtFprintfString-4         1.22µs ± 3%     1.22µs ± 4%     ~     (p=0.897 n=10+10)
FmtFprintfInt-4            1.27µs ± 2%     1.30µs ± 1%   +1.91%  (p=0.001 n=10+9)
FmtFprintfIntInt-4         1.83µs ± 2%     1.81µs ± 3%     ~     (p=0.149 n=10+10)
FmtFprintfPrefixedInt-4    1.80µs ± 3%     1.81µs ± 2%     ~     (p=0.421 n=10+8)
FmtFprintfFloat-4          6.89µs ± 3%     3.59µs ± 2%  -47.93%  (p=0.000 n=10+10)
FmtManyArgs-4              6.39µs ± 1%     6.09µs ± 1%   -4.61%  (p=0.000 n=10+9)
GobDecode-4                 109ms ± 2%       81ms ± 2%  -25.99%  (p=0.000 n=9+10)
GobEncode-4                 109ms ± 2%       76ms ± 2%  -29.88%  (p=0.000 n=10+9)
Gzip-4                      3.61s ± 1%      3.59s ± 1%     ~     (p=0.247 n=10+10)
Gunzip-4                    449ms ± 4%      450ms ± 1%     ~     (p=0.230 n=10+7)
HTTPClientServer-4         1.55ms ± 3%     1.53ms ± 2%     ~     (p=0.400 n=9+10)
JSONEncode-4                356ms ± 1%      183ms ± 1%  -48.73%  (p=0.000 n=10+10)
JSONDecode-4                1.12s ± 2%      0.87s ± 1%  -21.88%  (p=0.000 n=10+10)
Mandelbrot200-4             5.49s ± 1%      2.55s ± 1%  -53.45%  (p=0.000 n=9+10)
GoParse-4                  49.6ms ± 2%     47.5ms ± 1%   -4.08%  (p=0.000 n=10+9)
RegexpMatchEasy0_32-4      1.13µs ± 4%     1.20µs ± 4%   +6.42%  (p=0.000 n=10+10)
RegexpMatchEasy0_1K-4      4.41µs ± 2%     4.44µs ± 2%     ~     (p=0.128 n=10+10)
RegexpMatchEasy1_32-4      1.15µs ± 5%     1.20µs ± 5%   +4.85%  (p=0.002 n=10+10)
RegexpMatchEasy1_1K-4      6.21µs ± 2%     6.37µs ± 4%   +2.62%  (p=0.001 n=9+10)
RegexpMatchMedium_32-4     1.58µs ± 5%     1.65µs ± 3%   +4.85%  (p=0.000 n=10+10)
RegexpMatchMedium_1K-4      341µs ± 3%      351µs ± 7%     ~     (p=0.573 n=8+10)
RegexpMatchHard_32-4       21.4µs ± 3%     21.5µs ± 5%     ~     (p=0.931 n=9+9)
RegexpMatchHard_1K-4        626µs ± 2%      626µs ± 1%     ~     (p=0.645 n=8+8)
Revcomp-4                  46.4ms ± 2%     47.4ms ± 2%   +2.07%  (p=0.000 n=10+10)
Template-4                  1.31s ± 3%      1.23s ± 4%   -6.13%  (p=0.000 n=10+10)
TimeParse-4                4.49µs ± 1%     4.41µs ± 2%   -1.81%  (p=0.000 n=10+9)
TimeFormat-4               9.31µs ± 1%     9.32µs ± 2%     ~     (p=0.561 n=9+9)

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

golang.org/cl/102697 attempted to fix the span presentation by utilizing
the position of the span in the span slices of a task. But it is
not complete either.

First, id=0 is omitted in json encoding and the trace viewer silently
drops entries with the missing id field, so we must avoid zero-value id.
Second, it is possible that a goroutine handles multiple tasks. Then,
id collisions will happen.

This takes a simpler approach - have a counter that increments for every
emitSpan call, and use the value as the id value.

Change-Id: Idaa9505634acf6d327c6f00af32d8260955b85e1
Reviewed-on: https://go-review.googlesource.com/106755Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The current assembler will report error when the negative offset is in
the range of [-256, 0) and is not the multiples of 4/8.

The fix introduces C_NSAUTO_8, C_NSAUTO_4 and C_NAUTO4K. C_NPAUTO
includes C_NSAUTO_8 instead of C_NSAUTO, C_NAUTO4K includes C_NSAUTO_8,
C_NSAUTO_4 and C_NSAUTO. So that assembler will encode the negative offset
that is greater than -4095 and is not the multiples of 4/8 as two instructions.

Add the test cases.

Fixed #24471

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

The escape analysis models "loop depth". If the address of an
expression is assigned to something defined at a lower (outer)
loop depth, the escape analysis decides it escapes. However, it
uses the loop depth of the address operator instead of where
the RHS is defined. This causes an unnecessary escape if there is
an assignment inside a loop but the RHS is defined outside the
loop. This CL propagates the loop depth.

Fixes #24730.

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

This is more or less implied by the spec language on initialization,
but restate it for clarity.

Fixes #23112

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

If there are no certs, return an empty pool, not nil.

Fixes #21405

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

Fixes #23178

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

As an example of why this might happen,
consider this code from cmd/internal/objfile:

// Expand literal "$GOROOT" rewritten by obj.AbsFile()
filename = filepath.Clean(os.ExpandEnv(filename))

In this case, filename might not contain "$GOROOT",
in which case we can skip the buffer entirely.

name               old time/op    new time/op    delta
Expand/noop-8        46.7ns ± 1%    12.9ns ± 1%   -72.47%  (p=0.000 n=9+9)
Expand/multiple-8     139ns ± 1%     137ns ± 1%    -1.36%  (p=0.001 n=10+10)

The Expand/multiple improvement is probably noise.

This speeds up cmd/objdump detectably, if not much.
Using "benchcmd ObjdumpCompile go tool objdump `go tool -n compile`":

name            old time/op       new time/op       delta
ObjdumpCompile        9.35s ± 2%        9.07s ± 3%  -3.00%  (p=0.000 n=18+18)

Updates #24725

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

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

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

Fixes #24580

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

Users of TempFile need to be able to supply the suffix, especially
when using operating systems that give semantic meaning to the
filename extension such as Windows.  Renaming the file to include
an extension after the fact is insufficient as it could lead to
race conditions.

If the string given to TempFile includes a "*", the random string
replaces the "*". For example "myname.*.bat" will result in a random
filename such as "myname.123456.bat".  If no "*' is included the
old behavior is retained, and the random digits are appended to the
end.

If multiple "*" are included, the final one is replaced, thus
permitting a pathological programmer to create filenames such as
"foo*.123456.bat" but not "foo.123456.*.bat"

Fixes #4896

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

"MOVD $0xaaaaaaaa, R2"
"MOVD $-0x55555555, R3"

For the above instructions, 64-bit constants 0x00000000 aaaaaaaa
and 0xffffffff aaaaaaab are stored in the constant pool.

This CL optimizes them to
"MOVWU $0xaaaaaaaa, R2"
"MOVW $-0x05555555, R3"
and 32-bit constants 0xaaaaaaaa and 0xaaaaaaab are stored in the
constant pool.

There is a little size reduction (about total 5KB) in both the go
executable and the library files.

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

Fixes #24817

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

First, take the exclusive lock that ensures only one running binary
later: after assembling the gotest.app directory and signing it.

Second, don't pass -r to ios-deploy. The -r flag uninstalls the
app before installing it. It seems unnecessary, takes extra time
and if there was only the one developer app on the phone, it
will drop the developer permission on uninstall.

Change-Id: Ia222d3e5c2e1e2285f53074eb952941fd45fadd9
Reviewed-on: https://go-review.googlesource.com/106676Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

This commit includes efficiency improvements in two places in the
database/sql package where an "if err != nil" was redundant and
the error can be returned as-is (most of the code in the standard
library and even in the file I changed does it my suggested way).

Change-Id: Ib9dac69ed01ee846e570a776164cb87c2caee6ca
Reviewed-on: https://go-review.googlesource.com/106555Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The receiver was renamed 6 years ago in https://golang.org/cl/5674065
but the docs weren't updated to match.

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