Implement Lstat with fstatat and Lchown with Fchownat on
linux/amd64, linux/arm and linux/386. Furthermore, implement Stat
with fstatat on linux/arm and linux/386. Linux/arm64 already had
similar replacements.

The fstatat and fchownat system calls were added in kernel 2.6.16,
which is before the Go minimum, 2.6.23.

The three syscalls then match the android bionic implementation
and avoids the Android O seccomp filter.

Fixes #27797

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

The noopt builder is configured by setting GO_GCFLAGS=-N -l, but the
test/run.go test harness doesn't look at GO_GCFLAGS when processing
"errorcheck" files, it just calls compile:

  cmdline := []string{goTool(), "tool", "compile", /* etc */}

This is working as intended, since it makes the tests more robust and
independent from the environment; errorcheck files are supposed to set
additional building flags, when needed, like in:

  // errorcheck -0 -N -l

The test/bcecheck.go test used to work on the noopt builder (even if
bce is not active on -N -l) because the test was auto-contained and
the file always compiled with optimizations enabled.

In CL 107355, a new bce test dependent on an external package
(encoding.binary) was added. On the noopt builder the external package
is built using -N -l, and this causes a test failure that broke the
noopt builder:

  https://build.golang.org/log/b2be319536285e5807ee9d66d6d0ec4d57433768

To reproduce the failure, one can do:

  $ go install -a -gcflags="-N -l" std
  $ go run run.go -- checkbce.go

This change fixes the noopt builder breakage by removing the bce test
dependency on encoding/binary by defining a local Uint64() function to
be used in the test.

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

Previously consumeValue performed consumption of "unnecessary backslashes"
strictly for non-ASCII and non-token runes. Thus if it encountered a
backslash before a rune that is out of the ASCII range, it would
erroneously skip that backslash. This change now derestricts
"unnecessary backslash" unescaping for all character encodings,
using "isTSpecial" instead of "!isTokenChar".
This change is a follow-up of CL 32175.

Fixes #25888

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

The Fetch API returns a null body if there is no response body,
on browsers that support streaming the response body. This
change ensures we check for both undefined and null bodies
before attempting to read the body.

Fixes #27196

Change-Id: I0da86b61284fe394418b4b431495e715a037f335
Reviewed-on: https://go-review.googlesource.com/131236Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cloneHeader duplicates what Header.clone() method is doing. It's
used in a single place, which can be replaced with the use of the
method.

Change-Id: I6e8bbd6c95063f31ca3695f13fa7478873230525
GitHub-Last-Rev: eb08aeae9b4257df5cf08d6d30903ddeec6b6242
GitHub-Pull-Request: golang/go#27817
Reviewed-on: https://go-review.googlesource.com/136762Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Node.copy used to make a shallow copy of a node. Often, this is not
correct: If a node n's Orig field pointed to itself, the copy's Orig
field has to be adjusted to point to the copy. Otherwise, if n is
modified later, the copy's Orig appears modified as well (because it
points to n).

This was fixed for one specific case with
https://go-review.googlesource.com/c/go/+/136395 (issue #26855).

This change instead addresses copy in general:

In two cases we don't want the Orig adjustment as it causes escape
analysis output to fail (not match the existing error messages).
rawcopy is used in those cases.

In several cases Orig is set to the copy immediately after making
a copy; a new function sepcopy is used there.

Updates #26855.
Fixes #27765.

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

Move slice self-assign check into isSelfAssign function.
Make debug output consistent for all self-assignment cases.

Change-Id: I0e4cc7b3c1fcaeace7226dd80a0dc1ea97347a55
Reviewed-on: https://go-review.googlesource.com/136276
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

The ADDconstmodify has similar logic with other constmodify like
instructions. This CL optimize them to share code via fallthrough.
And the size of pkg/linux_386/cmd/compile/internal/x86.a decreases
about 0.3KB.

Change-Id: Ibdf06228afde875e8fe8e30851b50ca2be513dd9
Reviewed-on: https://go-review.googlesource.com/136398
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Found while tracking down #26855.

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

See the change and comment in typecheck.go for a detailed explanation.

Fixes #26855.

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

Use String and GoString methods instead of the xconf names
for the numeric conversion routines.

Also, fixed a couple of comments in fmt.go.

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

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

The fconv flag arguments were 0, FmtSharp, and FmtSharp|FmtSign.
The 0 value was used for binary representation only, which was
readily available via Mpflt.String. Otherwise, FmtSharp was always
passed. FmtSign was used to print the '+' sign in case of a positive
number and only needed for complex number formatting. Instead
implemented cconv and handled it there.

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

The current usage of sync.Pool is leaky because it stores an arbitrary
sized buffer into the pool. However, sync.Pool assumes that all items in the
pool are interchangeable from a memory cost perspective. Due to the unbounded
size of a buffer that may be added, it is possible for the pool to eventually
pin arbitrarily large amounts of memory in a live-lock situation.

As a simple fix, we just set a maximum size that we permit back into the pool.

We do not need to fix the use of a sync.Pool in scan.go since the free method
has always enforced a maximum capacity since the first commit of the scan logic.

Fixes #27740
Updates #23199

Change-Id: I875278f7dba42625405df36df3e9b028252ce5e3
Reviewed-on: https://go-review.googlesource.com/136116Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Some variants of Mercurial respond differently to “permission denied” errors
than to “file not found”, and we set HOME to point to an absolute path that may
produce the former instead of the latter.

To discourage Mercurial from trying HOME, give it an explicit (empty)
configuration in the working directory instead.

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

Clean mod cache should print remove commands and not run them when with set "-n" option.
Fixes #27458.

Change-Id: I97242cb40c062b347784cdb61653c84a3a7eab44
GitHub-Last-Rev: 5a6f10cad8c5f2c3916a74ca5eea27b1fdd1dc38
GitHub-Pull-Request: golang/go#27710
Reviewed-on: https://go-review.googlesource.com/135695
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Since there are no nested loops and/or switches,
loop label can be removed and "bare continue" can be used.

Change-Id: Id642a0859299e4470af544d59884fec51dbb31ee
Reviewed-on: https://go-review.googlesource.com/135837Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Teach samesafeexpr to handle arithmetic unary and binary ops.

It makes map lookup optimization possible in

	m[k+1] = append(m[k+1], ...)
	m[-k] = append(m[-k], ...)
	... etc

Does not cover "+" for strings (concatenation).

Change-Id: Ibbb16ac3faf176958da344be1471b06d7cf33a6c
Reviewed-on: https://go-review.googlesource.com/135795
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I4ee4f702e1bfc9ad9ea899c255104d5e18cf2c96
Reviewed-on: https://go-review.googlesource.com/135838Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently "arr[idx] |= 0x80" is compiled to MOVLload->BTSL->MOVLstore.
And this CL optimizes it to a single BTSLconstmodify. Other bit wise
operations with a direct memory operand are also implemented.

1. The size of the executable bin/go decreases about 4KB, and the total size
of pkg/linux_amd64 (excluding cmd/compile) decreases about 0.6KB.

2. There a little improvement in the go1 benchmark test (excluding noise).
name                     old time/op    new time/op    delta
BinaryTree17-4              2.66s ± 4%     2.66s ± 3%    ~     (p=0.596 n=49+49)
Fannkuch11-4                2.38s ± 2%     2.32s ± 2%  -2.69%  (p=0.000 n=50+50)
FmtFprintfEmpty-4          42.7ns ± 4%    43.2ns ± 7%  +1.31%  (p=0.009 n=50+50)
FmtFprintfString-4         71.0ns ± 5%    72.0ns ± 3%  +1.33%  (p=0.000 n=50+50)
FmtFprintfInt-4            80.7ns ± 4%    80.6ns ± 3%    ~     (p=0.931 n=50+50)
FmtFprintfIntInt-4          125ns ± 3%     126ns ± 4%    ~     (p=0.051 n=50+50)
FmtFprintfPrefixedInt-4     158ns ± 1%     142ns ± 3%  -9.84%  (p=0.000 n=36+50)
FmtFprintfFloat-4           215ns ± 4%     212ns ± 4%  -1.23%  (p=0.002 n=50+50)
FmtManyArgs-4               519ns ± 3%     510ns ± 3%  -1.77%  (p=0.000 n=50+50)
GobDecode-4                6.49ms ± 6%    6.52ms ± 5%    ~     (p=0.866 n=50+50)
GobEncode-4                5.93ms ± 8%    6.01ms ± 7%    ~     (p=0.076 n=50+50)
Gzip-4                      222ms ± 4%     224ms ± 8%  +0.80%  (p=0.001 n=50+50)
Gunzip-4                   36.6ms ± 5%    36.4ms ± 4%    ~     (p=0.093 n=50+50)
HTTPClientServer-4         59.1µs ± 1%    58.9µs ± 2%  -0.24%  (p=0.039 n=49+48)
JSONEncode-4               9.23ms ± 4%    9.21ms ± 5%    ~     (p=0.244 n=50+50)
JSONDecode-4               48.8ms ± 4%    48.7ms ± 4%    ~     (p=0.653 n=50+50)
Mandelbrot200-4            3.81ms ± 4%    3.80ms ± 3%    ~     (p=0.834 n=50+50)
GoParse-4                  3.20ms ± 5%    3.19ms ± 5%    ~     (p=0.494 n=50+50)
RegexpMatchEasy0_32-4      78.1ns ± 2%    77.4ns ± 3%  -0.86%  (p=0.005 n=50+50)
RegexpMatchEasy0_1K-4       233ns ± 3%     233ns ± 3%    ~     (p=0.074 n=50+50)
RegexpMatchEasy1_32-4      74.2ns ± 3%    73.4ns ± 3%  -1.06%  (p=0.000 n=50+50)
RegexpMatchEasy1_1K-4       369ns ± 2%     364ns ± 4%  -1.41%  (p=0.000 n=36+50)
RegexpMatchMedium_32-4      109ns ± 4%     107ns ± 3%  -2.06%  (p=0.001 n=50+50)
RegexpMatchMedium_1K-4     31.5µs ± 3%    30.8µs ± 3%  -2.20%  (p=0.000 n=50+50)
RegexpMatchHard_32-4       1.57µs ± 3%    1.56µs ± 2%  -0.57%  (p=0.016 n=50+50)
RegexpMatchHard_1K-4       47.4µs ± 4%    47.0µs ± 3%  -0.82%  (p=0.008 n=50+50)
Revcomp-4                   414ms ± 7%     412ms ± 7%    ~     (p=0.285 n=50+50)
Template-4                 64.3ms ± 4%    62.7ms ± 3%  -2.44%  (p=0.000 n=50+50)
TimeParse-4                 316ns ± 3%     313ns ± 3%    ~     (p=0.122 n=50+50)
TimeFormat-4                291ns ± 3%     293ns ± 3%  +0.80%  (p=0.001 n=50+50)
[Geo mean]                 46.5µs         46.2µs       -0.81%

name                     old speed      new speed      delta
GobDecode-4               118MB/s ± 6%   118MB/s ± 5%    ~     (p=0.863 n=50+50)
GobEncode-4               130MB/s ± 9%   128MB/s ± 8%    ~     (p=0.076 n=50+50)
Gzip-4                   87.4MB/s ± 4%  86.8MB/s ± 7%  -0.78%  (p=0.002 n=50+50)
Gunzip-4                  531MB/s ± 5%   533MB/s ± 4%    ~     (p=0.093 n=50+50)
JSONEncode-4              210MB/s ± 4%   211MB/s ± 5%    ~     (p=0.247 n=50+50)
JSONDecode-4             39.8MB/s ± 4%  39.9MB/s ± 4%    ~     (p=0.654 n=50+50)
GoParse-4                18.1MB/s ± 5%  18.2MB/s ± 5%    ~     (p=0.493 n=50+50)
RegexpMatchEasy0_32-4     410MB/s ± 2%   413MB/s ± 3%  +0.86%  (p=0.004 n=50+50)
RegexpMatchEasy0_1K-4    4.39GB/s ± 3%  4.38GB/s ± 3%    ~     (p=0.063 n=50+50)
RegexpMatchEasy1_32-4     432MB/s ± 3%   436MB/s ± 3%  +1.07%  (p=0.000 n=50+50)
RegexpMatchEasy1_1K-4    2.77GB/s ± 2%  2.81GB/s ± 4%  +1.46%  (p=0.000 n=36+50)
RegexpMatchMedium_32-4   9.16MB/s ± 3%  9.35MB/s ± 4%  +2.09%  (p=0.001 n=50+50)
RegexpMatchMedium_1K-4   32.5MB/s ± 3%  33.2MB/s ± 3%  +2.25%  (p=0.000 n=50+50)
RegexpMatchHard_32-4     20.4MB/s ± 3%  20.5MB/s ± 2%  +0.56%  (p=0.017 n=50+50)
RegexpMatchHard_1K-4     21.6MB/s ± 4%  21.8MB/s ± 3%  +0.83%  (p=0.008 n=50+50)
Revcomp-4                 613MB/s ± 4%   618MB/s ± 7%    ~     (p=0.152 n=48+50)
Template-4               30.2MB/s ± 4%  30.9MB/s ± 3%  +2.49%  (p=0.000 n=50+50)
[Geo mean]                127MB/s        128MB/s       +0.64%

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

Change-Id: I5afba2c10372252be4b65dae7a95461722de904f
Reviewed-on: https://go-review.googlesource.com/135835Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

AMD64's ADDQconstmodify/ADDLconstmodify have similar logic with
other constmodify like operators, but seperated case statements.
This CL simplify them with a fallthrough.

Change-Id: Ia73ffeaddc5080182f68c06c9d9b48fe32a14e38
Reviewed-on: https://go-review.googlesource.com/135855
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Updates #26148

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

The rules are subtle, but under some circumstances the result
can be constant. Mention this and refer to the appropriate
section of the specification.

Fixes #27588.

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

That optimization is not valid if x == -0.

The test is a bit tricky because 0 == -0. We distinguish
0 from -0 with 1/0 == inf, 1/-0 == -inf.

This has been a bug since CL 24790 in Go 1.8. Probably doesn't
warrant a backport.

Fixes #27718

Note: the optimization x-0 -> x is actually valid.
But it's probably best to take it out, so as to not confuse readers.

Change-Id: I99f16a93b45f7406ec8053c2dc759a13eba035fa
Reviewed-on: https://go-review.googlesource.com/135701Reviewed-by: Cherry Zhang <cherryyz@google.com>

They aren't really races, or at least they don't have any
observable effect. The spec is silent on whether these are actually
races or not.

Fix this problem by not using the address of len (or of cap)
as the location where channel operations are recorded to occur.
Use a random other field of hchan for that.

I'm not 100% sure we should in fact fix this. Opinions welcome.

Fixes #27070

Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084
Reviewed-on: https://go-review.googlesource.com/135698Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

On Linux, sysUnused currently uses madvise(MADV_DONTNEED) to signal the
kernel that a range of allocated memory contains unneeded data. After a
successful call, the range (but not the data it contained before the
call to madvise) is still available but the first access to that range
will unconditionally incur a page fault (needed to 0-fill the range).

A faster alternative is MADV_FREE, available since Linux 4.5. The
mechanism is very similar, but the page fault will only be incurred if
the kernel, between the call to madvise and the first access, decides to
reuse that memory for something else.

In sysUnused, test whether MADV_FREE is supported and fall back to
MADV_DONTNEED in case it isn't. This requires making the return value of
the madvise syscall available to the caller, so change runtime.madvise
to return it.

Fixes #23687

Change-Id: I962c3429000dd9f4a00846461ad128b71201bb04
Reviewed-on: https://go-review.googlesource.com/135395
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

For types defined as:

type typename struct { ... }

the linker produces two DIEs: (1) a DW_TAG_structure_type DIE and (2) a
DW_TAG_typedef_type DIE having (1) as its type attribute.

All subsequent references to 'typename' should use the
DW_TAG_typedef_type DIE, not the DW_TAG_structure_type. Mostly this is
true but sometimes one reference will use the DW_TAG_structure_type
directly. In particular, this happens to the 'first' reference to the
type in question (where 'first' means whatever happens first in the way
the linker scans its symbols).

This isn't only true of struct types: pointer types, array types, etc.
can also be affected.

This fix solves the problem by always returning the typedef DIE in
newtype, when one is created.

Fixes #27614

Change-Id: Ia65b4a1d8c2b752e33a4ebdb74ccd92faa69526e
Reviewed-on: https://go-review.googlesource.com/134555
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>

Fixes #27731

Change-Id: Ifb4d57923b1bba0210ec1f623d779d7b5f442812
Reviewed-on: https://go-review.googlesource.com/135995
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The -mod=release flag is not supported, so this appears to be a
documentation mistake.

Fixes #27354.

Change-Id: I895e8d5b4918adcb1f605361773173f312fa7b65
GitHub-Last-Rev: 42bfe0c11e38c90e76887771654ea81af98d50ec
GitHub-Pull-Request: golang/go#27358
Reviewed-on: https://go-review.googlesource.com/132116
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Makes use of bounded shift information to generate
more efficient shift instructions.

Updates #25167 for ppc64x

Change-Id: I7fc8d49a3fb3e0f273cc51bc767470b239cbdca7
Reviewed-on: https://go-review.googlesource.com/135380
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>

Fixes missing commas where it wasn't immediately apparent whether
"requests" was being used as a verb or a noun.

Change-Id: Ic8c99b4f46475f40a6160d26a3cd11c215940dd5
GitHub-Last-Rev: 1becf6fabeb6f928e37526e96297dd60397ccf9b
GitHub-Pull-Request: golang/go#27649
Reviewed-on: https://go-review.googlesource.com/135135Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

Change-Id: Idcd79788e64947a927af662b6394ac7218e62ba8
Reviewed-on: https://go-review.googlesource.com/135836Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

According to AMD64.rules, BTS&BTR&BTC use arg1 as the bit index,
while BT uses arg0. This CL fixes the wrong comment message in
AMD64Ops.go, which indicates all bit indexes are in arg0.

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

If a cyclic declaration uses a non-type object where it expects
a type, don't report the cycle error in favor of the clearer and
more informative error about the missing type.

Fixes #25790.

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

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

Fixes: #27298

Change-Id: Icfc6992b470136bb25a77912f670a25883642316
Reviewed-on: https://go-review.googlesource.com/132095Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Use float <-> int register moves without conversion instead of stores
and loads to move float <-> int values.

Math package benchmark results.
name                 old time/op  new time/op  delta
Acosh                 153ns ± 0%   147ns ± 0%   -3.92%  (p=0.000 n=10+10)
Asinh                 183ns ± 0%   177ns ± 0%   -3.28%  (p=0.000 n=10+10)
Atanh                 157ns ± 0%   155ns ± 0%   -1.27%  (p=0.000 n=10+10)
Atan2                 118ns ± 0%   117ns ± 1%   -0.59%  (p=0.003 n=10+10)
Cbrt                  119ns ± 0%   114ns ± 0%   -4.20%  (p=0.000 n=10+10)
Copysign             7.51ns ± 0%  6.51ns ± 0%  -13.32%  (p=0.000 n=9+10)
Cos                  73.1ns ± 0%  70.6ns ± 0%   -3.42%  (p=0.000 n=10+10)
Cosh                  119ns ± 0%   121ns ± 0%   +1.68%  (p=0.000 n=10+9)
ExpGo                 154ns ± 0%   149ns ± 0%   -3.05%  (p=0.000 n=9+10)
Expm1                 101ns ± 0%    99ns ± 0%   -1.88%  (p=0.000 n=10+10)
Exp2Go                150ns ± 0%   146ns ± 0%   -2.67%  (p=0.000 n=10+10)
Abs                  7.01ns ± 0%  6.01ns ± 0%  -14.27%  (p=0.000 n=10+9)
Mod                   234ns ± 0%   212ns ± 0%   -9.40%  (p=0.000 n=9+10)
Frexp                34.5ns ± 0%  30.0ns ± 0%  -13.04%  (p=0.000 n=10+10)
Gamma                 112ns ± 0%   111ns ± 0%   -0.89%  (p=0.000 n=10+10)
Hypot                73.6ns ± 0%  68.6ns ± 0%   -6.79%  (p=0.000 n=10+10)
HypotGo              77.1ns ± 0%  72.1ns ± 0%   -6.49%  (p=0.000 n=10+10)
Ilogb                31.0ns ± 0%  28.0ns ± 0%   -9.68%  (p=0.000 n=10+10)
J0                    437ns ± 0%   434ns ± 0%   -0.62%  (p=0.000 n=10+10)
J1                    433ns ± 0%   431ns ± 0%   -0.46%  (p=0.000 n=10+10)
Jn                    927ns ± 0%   922ns ± 0%   -0.54%  (p=0.000 n=10+10)
Ldexp                41.5ns ± 0%  37.0ns ± 0%  -10.84%  (p=0.000 n=9+10)
Log                   124ns ± 0%   118ns ± 0%   -4.84%  (p=0.000 n=10+9)
Logb                 34.0ns ± 0%  32.0ns ± 0%   -5.88%  (p=0.000 n=10+10)
Log1p                 110ns ± 0%   108ns ± 0%   -1.82%  (p=0.000 n=10+10)
Log10                 136ns ± 0%   132ns ± 0%   -2.94%  (p=0.000 n=10+10)
Log2                 51.6ns ± 0%  47.1ns ± 0%   -8.72%  (p=0.000 n=10+10)
Nextafter32          33.0ns ± 0%  30.5ns ± 0%   -7.58%  (p=0.000 n=10+10)
Nextafter64          29.0ns ± 0%  26.5ns ± 0%   -8.62%  (p=0.000 n=10+10)
PowInt                169ns ± 0%   160ns ± 0%   -5.33%  (p=0.000 n=10+10)
PowFrac               375ns ± 0%   361ns ± 0%   -3.73%  (p=0.000 n=10+10)
RoundToEven          14.0ns ± 0%  12.5ns ± 0%  -10.71%  (p=0.000 n=10+10)
Remainder             206ns ± 0%   192ns ± 0%   -6.80%  (p=0.000 n=10+9)
Signbit              6.01ns ± 0%  5.51ns ± 0%   -8.32%  (p=0.000 n=10+9)
Sin                  70.1ns ± 0%  69.6ns ± 0%   -0.71%  (p=0.000 n=10+10)
Sincos               99.1ns ± 0%  99.6ns ± 0%   +0.50%  (p=0.000 n=9+10)
SqrtGoLatency         178ns ± 0%   146ns ± 0%  -17.70%  (p=0.000 n=8+10)
SqrtPrime            9.19µs ± 0%  9.20µs ± 0%   +0.01%  (p=0.000 n=9+9)
Tanh                  125ns ± 1%   127ns ± 0%   +1.36%  (p=0.000 n=10+10)
Y0                    428ns ± 0%   426ns ± 0%   -0.47%  (p=0.000 n=10+10)
Y1                    431ns ± 0%   429ns ± 0%   -0.46%  (p=0.000 n=10+9)
Yn                    906ns ± 0%   901ns ± 0%   -0.55%  (p=0.000 n=10+10)
Float64bits          4.50ns ± 0%  3.50ns ± 0%  -22.22%  (p=0.000 n=10+10)
Float64frombits      4.00ns ± 0%  3.50ns ± 0%  -12.50%  (p=0.000 n=10+9)
Float32bits          4.50ns ± 0%  3.50ns ± 0%  -22.22%  (p=0.002 n=8+10)
Float32frombits      4.00ns ± 0%  3.50ns ± 0%  -12.50%  (p=0.000 n=10+10)

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

For sweep events, we used to modify the ViewerEvent returned from
ctx.emitSlice later in order to embed more details about the sweep
operation. The trick no longer works after the change
https://golang.org/cl/92375 and caused a regression.

ctx.emit method encodes the ViewerEvent, so any modification to the
ViewerEvent object after ctx.emit returns will not be reflected.

Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing
slices for SWEEP. ctx.emit* methods are meant to truely emit
ViewerEvents.

Fixes #27711

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

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