Fixes #19223.

Change-Id: I4cc8e81559a1313e1477ee36902e1b653155a888
Reviewed-on: https://go-review.googlesource.com/37374Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Args may be not at 8-byte aligned offset to SP. When the stack
frame is large, folding the offset of args may cause large
unaligned offsets that does not fit in a machine instruction on
ARM64. Therefore disable folding offsets for args.

This has small performance impact (see below). A better fix would
be letting the assembler backend fix up the offset by loading it
into a register if it doesn't fit into an instruction. And the
compiler can simply generate large load/stores with offset. Since
in most of the cases the offset is aligned or the stack frame is
small, it can fit in an instruction and no fixup is needed. But
this is too complicated for Go 1.8.

name                     old time/op    new time/op    delta
BinaryTree17-8              8.30s ± 0%     8.31s ± 0%    ~     (p=0.579 n=10+10)
Fannkuch11-8                6.14s ± 0%     6.18s ± 0%  +0.53%  (p=0.000 n=9+10)
FmtFprintfEmpty-8           117ns ± 0%     117ns ± 0%    ~     (all equal)
FmtFprintfString-8          196ns ± 0%     197ns ± 0%  +0.72%  (p=0.000 n=10+10)
FmtFprintfInt-8             204ns ± 0%     205ns ± 0%  +0.49%  (p=0.000 n=9+10)
FmtFprintfIntInt-8          302ns ± 0%     307ns ± 1%  +1.46%  (p=0.000 n=10+10)
FmtFprintfPrefixedInt-8     329ns ± 2%     326ns ± 0%    ~     (p=0.083 n=10+10)
FmtFprintfFloat-8           540ns ± 0%     542ns ± 0%  +0.46%  (p=0.000 n=8+7)
FmtManyArgs-8              1.20µs ± 1%    1.19µs ± 1%  -1.02%  (p=0.000 n=10+10)
GobDecode-8                17.3ms ± 1%    17.8ms ± 0%  +2.75%  (p=0.000 n=10+7)
GobEncode-8                15.3ms ± 1%    15.4ms ± 0%  +0.57%  (p=0.004 n=9+10)
Gzip-8                      789ms ± 0%     803ms ± 0%  +1.78%  (p=0.000 n=9+10)
Gunzip-8                    128ms ± 0%     130ms ± 0%  +1.73%  (p=0.000 n=10+9)
HTTPClientServer-8          202µs ± 6%     201µs ±10%    ~     (p=0.739 n=10+10)
JSONEncode-8               42.0ms ± 0%    42.1ms ± 0%  +0.19%  (p=0.028 n=10+9)
JSONDecode-8                159ms ± 0%     161ms ± 0%  +1.05%  (p=0.000 n=9+10)
Mandelbrot200-8            10.1ms ± 0%    10.1ms ± 0%  -0.07%  (p=0.000 n=10+9)
GoParse-8                  8.46ms ± 1%    8.61ms ± 1%  +1.77%  (p=0.000 n=10+10)
RegexpMatchEasy0_32-8       227ns ± 1%     226ns ± 0%  -0.35%  (p=0.001 n=10+9)
RegexpMatchEasy0_1K-8      1.63µs ± 0%    1.63µs ± 0%  -0.13%  (p=0.000 n=10+9)
RegexpMatchEasy1_32-8       250ns ± 0%     249ns ± 0%  -0.40%  (p=0.001 n=8+9)
RegexpMatchEasy1_1K-8      2.07µs ± 0%    2.08µs ± 0%  +0.05%  (p=0.027 n=9+9)
RegexpMatchMedium_32-8      350ns ± 0%     350ns ± 0%    ~     (p=0.412 n=9+8)
RegexpMatchMedium_1K-8      104µs ± 0%     104µs ± 0%  +0.31%  (p=0.000 n=10+7)
RegexpMatchHard_32-8       5.82µs ± 0%    5.82µs ± 0%    ~     (p=0.937 n=9+9)
RegexpMatchHard_1K-8        176µs ± 0%     176µs ± 0%  +0.03%  (p=0.000 n=9+8)
Revcomp-8                   1.36s ± 1%     1.37s ± 1%    ~     (p=0.218 n=10+10)
Template-8                  151ms ± 1%     156ms ± 1%  +3.21%  (p=0.000 n=10+10)
TimeParse-8                 737ns ± 0%     758ns ± 2%  +2.74%  (p=0.000 n=10+10)
TimeFormat-8                801ns ± 2%     789ns ± 1%  -1.51%  (p=0.000 n=10+10)
[Geo mean]                  142µs          143µs       +0.50%

Fixes #19137.

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

For compatibility with math/bits uint operations.

When math/big was written originally, the Go compiler used 32bit
int/uint values even on a 64bit machine. uintptr was the type that
represented the machine register size. Now, the int/uint types are
sized to the native machine register size, so they are the natural
machine Word type.

On most machines, the size of int/uint correspond to the size of
uintptr. On platforms where uint and uintptr have different sizes,
this change may lead to performance differences (e.g., amd64p32).

Change-Id: Ief249c160b707b6441848f20041e32e9e9d8d8ca
Reviewed-on: https://go-review.googlesource.com/37372
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The type of the OffPtr should be consistent with the type of the
following load. Before this CL it was typed as a pointer to the
struct.

Fixes #19164.

Change-Id: Ibcdec4411c6f719702f76f8dba3cce8691bfbe0c
Reviewed-on: https://go-review.googlesource.com/37254
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

Fixes #18772

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

Found by vet.

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

Found by vet.

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

Change-Id: I62118e197190af1d11a89921d5769101ce6d2257
Reviewed-on: https://go-review.googlesource.com/37306
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

doEncryptKeyAsm is tail-called from other assembly routines.
Give it a proper prototype so that vet can check it.
Adjust one assembly FP reference accordingly.

Change-Id: I263fcb0191529214b16e6bd67330fadee492eef4
Reviewed-on: https://go-review.googlesource.com/37305
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

A last-minute rollback of a change left some
unreachable code that we don't want to remove.

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

Change-Id: I721045120a4df41462c02252e2e5e8529ae2d694
Reviewed-on: https://go-review.googlesource.com/37303
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: Ib942cb9e0cb20821aea4274bc3ddc83a215afbcb
Reviewed-on: https://go-review.googlesource.com/37302
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I689b2e8e214561350f88fa4e20c8f34cf69dc6a7
Reviewed-on: https://go-review.googlesource.com/37301
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/vet has a known deficiency in its handling of fmt.Formatters.
This causes a spurious printf error only for non-host platforms.
Since cmd/vet/all may get run on any given platform,
whitelists cannot help here.

Work around the issue by skipping printf tests entirely
for non-host platforms.

Work around the one known acceptable false positive from vet
by whitelisting the file that contains it.

Change-Id: Id74b3d4db0519cf9a670a065683715f856266e45
Reviewed-on: https://go-review.googlesource.com/36936Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Stop reporting errors from cmd.Process.Kill; they don't matter for
purposes of this test, and they can occur if the process exits quickly.

Fixes #19211.
Fixes #19213.

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

storeOrder visits values in DFS order. It should "break" after
pushing one argument to stack, instead of "continue".

Fixes #19179.

Change-Id: I561afb44213df40ebf8bf7d28e0fd00f22a81ac0
Reviewed-on: https://go-review.googlesource.com/37250
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>

No functional changes.

For #10776.

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

dwarf writing code assumes that dwarf sections follow
.data and .bss, not .ctors. Make pe section writing code
match that assumption.

For #10776.

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

The symbols get in a way when using external linker. They are
not associated with a section. And linker fails when
generating relocations for them.

__image_base__ and _image_base__ have been added long time ago.
I do not think they are needed anymore. If I delete them, all
tests still PASS. I tried going back to the commit that added
them to see if I can reproduce original error, but I cannot
build it. I don't have hg version of go repo, and my gcc is
complaining about cc source code.

I wasted too much time with this, so I decided to leave them only
for internal linker. That is what they were originally added for.

For #10776.

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

dwarf relocations refer to dwarf section symbols, so dwarf
section symbols must be present in pe symbol table before we
write dwarf relocations.

.ctors pe section already refer to .text symbol.

Write all pe section name symbols into symbol table, so we
can use them whenever we need them.

This CL also simplified some code.

For #10776.

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

Introduce a slice that keeps long pe section names as we add them.
It will be used later to output pe symbol table and dwarf relocations.

For #10776.

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

This is what gcc does when it generates object files.
And pecoff.doc says: "for simplicity, compilers should
 set this to zero". It is easier to count everything,
when it starts from 0. Make go linker do the same.

For #10776.

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

Flaky tests hurt productivity. Disable for now.

Updates #19139

Change-Id: I2e3040bdf0e53597a1c4f925b788e3268ea284c1
Reviewed-on: https://go-review.googlesource.com/37291
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #19189.

Change-Id: Ice69216c7fc2eaeb3dbbdcd08a8284204c7f52ef
Reviewed-on: https://go-review.googlesource.com/37237
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change list https://golang.org/cl/37015/ moved the optimization
of division by constants to the generic ssa backend.
This removes the old now unused code that was used
for this optimization outside of the ssa backend.

Change-Id: I86223e56742e48dbb372ba8d779681e66448c513
Reviewed-on: https://go-review.googlesource.com/37198
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>

Using some additional suggestions per "Hacker's Delight".
Added documentation and extra tests.

Measured on 1.7 GHz Intel Core i7, running macOS 10.12.3.

benchmark                  old ns/op     new ns/op     delta
BenchmarkOnesCount-4       7.34          5.38          -26.70%
BenchmarkOnesCount8-4      2.03          1.98          -2.46%
BenchmarkOnesCount16-4     2.56          2.50          -2.34%
BenchmarkOnesCount32-4     2.98          2.39          -19.80%
BenchmarkOnesCount64-4     4.22          2.96          -29.86%

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

Change list https://golang.org/cl/20686/ removed the last use
of the variable byteType.

Change-Id: I4ea79095136a49a9d22767b37f48f3404da05056
Reviewed-on: https://go-review.googlesource.com/37197
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

XCHG needs to allow the stack pointer as an argument because we have a
rewrite that incorporates the address of a local variable into the
instruction.

Fixes #19184

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

Before the change, `go env` reports PKG_CONFIG in between the
CGO env group:

    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOOS="darwin"
    GOPATH="/Users/jbd"
    GORACE=""
    GOROOT="/Users/jbd/go"
    GOTOOLDIR="/Users/jbd/go/pkg/tool/darwin_amd64"
    GCCGO="gccgo"
    CC="clang"
    GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lq/qcn67khn4_1b41_g48x3zchh005d21/T/go-build184491598=/tmp/go-build -gno-record-gcc-switches -fno-common"
    CXX="clang++"
    CGO_ENABLED="1"
    PKG_CONFIG="pkg-config"
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"

The change makes PKG_CONFIG to be reported as the final item,
and not breaking the CGO_* group apart.

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

Added an alternate form of printing floats and complex values
by specifying the sharp flag.

Output formatted using the the verbs v, e, E, f, F, g and G in
combination with the sharp flag will always include a decimal point.

The alternate form specified by the sharp flag for %g and %G verbs
will not truncate trailing zeros and assume a default precision of 6.

Fixes #18857.

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

Fixes #19110

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

Add exported global variables and store the results of benchmarked
functions in them. This prevents the current compiler optimizations
from removing the instructions that are needed to compute the return
values of the benchmarked functions.

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

The below range loop will not stop when encountering
the first '.' character in a Darwin version string like "15.6.0".

for i = range osver {
   if osver[i] != '.' {
         continue
      }
   }
}

Therefore, the condition i > 2 was always satisfied and
supportsCloseOnExec was always set to true.

Since the minimum supported version of OSX for go is currently 10.8
and O_CLOEXEC is implemented from OSX 10.7 on the detection code
can be removed and support for O_CLOEXEC is always assumed to exist.

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

The emphasize function used a complex regexp to find URLs, which
truncated some types of URL and did not match others.
This has been simplified and adjusted to allow valid punctuation
like :: or ! in the path part and :[] in the host part.
Comments were added to clarify what this regexp allows.
The path part matches query and fragment also so document this.
Removed news, telnet, wais, and prospero protocols.

Tests were added for:
 IPV6 URLs
 URLs surrounded by brackets
 URLs containing ::
 URLs containing :;!- in the path

In order to allow punctuation and yet preserve current behaviour,
URLs are not permitted to end in .,:;?! to allow the use of
normal punctuation surrounding URLs in comments.

Fixes #18139

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

BenchmarkLeadingZeros-8      	200000000	         8.80 ns/op
BenchmarkLeadingZeros8-8     	200000000	         8.21 ns/op
BenchmarkLeadingZeros16-8    	200000000	         7.49 ns/op
BenchmarkLeadingZeros32-8    	200000000	         7.80 ns/op
BenchmarkLeadingZeros64-8    	200000000	         8.67 ns/op

BenchmarkTrailingZeros-8     	1000000000	         2.05 ns/op
BenchmarkTrailingZeros8-8    	2000000000	         1.94 ns/op
BenchmarkTrailingZeros16-8   	2000000000	         1.94 ns/op
BenchmarkTrailingZeros32-8   	2000000000	         1.92 ns/op
BenchmarkTrailingZeros64-8   	2000000000	         2.03 ns/op

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

Measured on 2.3 GHz Intel Core i7, running maxOS 10.12.3.

benchmark                    old ns/op     new ns/op     delta
BenchmarkRotateLeft-8        7.87          7.00          -11.05%
BenchmarkRotateLeft8-8       8.41          4.52          -46.25%
BenchmarkRotateLeft16-8      8.07          4.55          -43.62%
BenchmarkRotateLeft32-8      8.36          4.73          -43.42%
BenchmarkRotateLeft64-8      7.93          4.78          -39.72%

BenchmarkRotateRight-8       8.23          6.72          -18.35%
BenchmarkRotateRight8-8      8.76          4.39          -49.89%
BenchmarkRotateRight16-8     9.07          4.44          -51.05%
BenchmarkRotateRight32-8     8.85          4.46          -49.60%
BenchmarkRotateRight64-8     8.11          4.43          -45.38%

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

Also: Changed Reverse/ReverseBytes implementations to use
the same (smaller) masks as OnesCount.

BenchmarkOnesCount-8          37.0          6.26          -83.08%
BenchmarkOnesCount8-8         7.24          1.99          -72.51%
BenchmarkOnesCount16-8        11.3          2.47          -78.14%
BenchmarkOnesCount32-8        18.4          3.02          -83.59%
BenchmarkOnesCount64-8        40.0          3.78          -90.55%
BenchmarkReverse-8            6.69          6.22          -7.03%
BenchmarkReverse8-8           1.64          1.64          +0.00%
BenchmarkReverse16-8          2.26          2.18          -3.54%
BenchmarkReverse32-8          2.88          2.87          -0.35%
BenchmarkReverse64-8          5.64          4.34          -23.05%
BenchmarkReverseBytes-8       2.48          2.17          -12.50%
BenchmarkReverseBytes16-8     0.63          0.95          +50.79%
BenchmarkReverseBytes32-8     1.13          1.24          +9.73%
BenchmarkReverseBytes64-8     2.50          2.16          -13.60%

OnesCount-8       37.0ns ± 0%   6.3ns ± 0%   ~             (p=1.000 n=1+1)
OnesCount8-8      7.24ns ± 0%  1.99ns ± 0%   ~             (p=1.000 n=1+1)
OnesCount16-8     11.3ns ± 0%   2.5ns ± 0%   ~             (p=1.000 n=1+1)
OnesCount32-8     18.4ns ± 0%   3.0ns ± 0%   ~             (p=1.000 n=1+1)
OnesCount64-8     40.0ns ± 0%   3.8ns ± 0%   ~             (p=1.000 n=1+1)
Reverse-8         6.69ns ± 0%  6.22ns ± 0%   ~             (p=1.000 n=1+1)
Reverse8-8        1.64ns ± 0%  1.64ns ± 0%   ~     (all samples are equal)
Reverse16-8       2.26ns ± 0%  2.18ns ± 0%   ~             (p=1.000 n=1+1)
Reverse32-8       2.88ns ± 0%  2.87ns ± 0%   ~             (p=1.000 n=1+1)
Reverse64-8       5.64ns ± 0%  4.34ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes-8    2.48ns ± 0%  2.17ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes16-8  0.63ns ± 0%  0.95ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes32-8  1.13ns ± 0%  1.24ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes64-8  2.50ns ± 0%  2.16ns ± 0%   ~             (p=1.000 n=1+1)

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

On AMD64 Most operation can have one operand in memory.
Combine load and dependand operation into one new operation,
where possible. I've seen no significant performance changes on go1,
but this allows to remove ~1.8kb code from go tool. And in math package
I see e. g.:

Remainder-6            70.0ns ± 0%   64.6ns ± 0%   -7.76%  (p=0.000 n=9+1
Change-Id: I88b8602b1d55da8ba548a34eb7da4b25d59a297e
Reviewed-on: https://go-review.googlesource.com/36793
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

The type of an intermediate multiply was wrong.  When that
intermediate multiply was spilled, the top 32 bits were lost.

Fixes #19153

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

- moved from: x&m>>k | x&^m<<k to: x&m>>k | x<<k&m
  This permits use of the same constant m twice (*) which may be
  better for machines that can't use large immediate constants
  directly with an AND instruction and have to load them explicitly.
  *) CPUs don't usually have a &^ instruction, so x&^m becomes x&(^m)

- simplified returns
  This improves the generated code because the compiler recognizes
  x>>k | x<<k as ROT when k is the bitsize of x.

The 8-bit versions of these instructions can be significantly faster
still if they are replaced with table lookups, as long as the table
is in cache. If the table is not in cache, table-lookup is probably
slower, hence the choice of an explicit register-only implementation
for now.

BenchmarkReverse-8            8.50          6.86          -19.29%
BenchmarkReverse8-8           2.17          1.74          -19.82%
BenchmarkReverse16-8          2.89          2.34          -19.03%
BenchmarkReverse32-8          3.55          2.95          -16.90%
BenchmarkReverse64-8          6.81          5.57          -18.21%
BenchmarkReverseBytes-8       3.49          2.48          -28.94%
BenchmarkReverseBytes16-8     0.93          0.62          -33.33%
BenchmarkReverseBytes32-8     1.55          1.13          -27.10%
BenchmarkReverseBytes64-8     2.47          2.47          +0.00%

Reverse-8         8.50ns ± 0%  6.86ns ± 0%   ~             (p=1.000 n=1+1)
Reverse8-8        2.17ns ± 0%  1.74ns ± 0%   ~             (p=1.000 n=1+1)
Reverse16-8       2.89ns ± 0%  2.34ns ± 0%   ~             (p=1.000 n=1+1)
Reverse32-8       3.55ns ± 0%  2.95ns ± 0%   ~             (p=1.000 n=1+1)
Reverse64-8       6.81ns ± 0%  5.57ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes-8    3.49ns ± 0%  2.48ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes16-8  0.93ns ± 0%  0.62ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes32-8  1.55ns ± 0%  1.13ns ± 0%   ~             (p=1.000 n=1+1)
ReverseBytes64-8  2.47ns ± 0%  2.47ns ± 0%   ~     (all samples are equal)

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