Change the closures to methods on debugState, mostly just for aesthetic
reasons.

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

changedVars was functionally a set, but couldn't be iterated over
efficiently. In functions with many variables, the wasted iteration was
costly. Use a sparseSet instead.

(*gc.Node).String() is very expensive: it calls Sprintf, which does
reflection, etc, etc. Instead, just look at .Sym.Name, which is all we
care about.

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

Replace the OnStack boolean in VarLoc with a flag bit in StackOffset.
This doesn't get much memory savings since it's still 64-bit aligned,
but does seem to help a bit anyway.

Change liveSlot to fit into 16 bytes. Because nested structs still get
padding, this required inlining it. Fortunately there's not much logic
to copy.

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

For now, limited to the most repetitive rules that are also short and
simple, so that we can have a substantial conciseness win without
compromising rules readability.

Ran rulegen, no changes in the rewrite files.

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

Fixes #24006

Change-Id: Ic1438b121fe705f9a6e3ed8340882e9dfd26ecf7
Reviewed-on: https://go-review.googlesource.com/95916Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>

For now, limited to the most repetitive rules that are also short and
simple, so that we can have a substantial conciseness win without
compromising rules readability.

Ran rulegen, no change in the actual compiler code (as expected).

Change-Id: Ia74acc389cd8310eb7fe8f927171fa3d292d2a86
Reviewed-on: https://go-review.googlesource.com/95797Reviewed-by: Giovanni Bajo <rasky@develer.com>

For now, limited to the most repetitive rules that are also short and
simple, so that we can have a substantial conciseness win without
compromising rules readability.

Ran rulegen, no change in the actual compiler code (as expected).

Change-Id: Ib0bfbbc181fcec095fb78ac752addd1eee0c3575
Reviewed-on: https://go-review.googlesource.com/95796Reviewed-by: Giovanni Bajo <rasky@develer.com>

No changes in the generated file, as expected.

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

We did warn on them in some cases, but not others. In particular, if one
used a slice composite literal with struct pointer elements, and omitted
the type of an element's composite literal, it would not get any warning
even if it should get one.

The issue is that typ.Underlying() can be of type *types.Pointer. Skip
those levels of indirection before checking for a *types.Struct
underlying type.

isLocalType also needed a bit of tweaking to ignore dereferences.
Perhaps that can be rewritten now that we have type info, but let's
leave it for another time.

Fixes #23539.

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

Sometimes, multiple CLs being merged that create rules on the same
opcodes can cause the generated file to differ compared to a new
regeneration. This is caused by the fact that rulegen splits
generated functions in chunks of 10 rules per function (to avoid
creating functions that are too big). If two CLs add rules to
the same function, they might cause a generated function to
have more than 10 rules, even though each CL individually didn't
pass this limit.

Change-Id: Ib641396b7e9028f80ec8718746969d390a9fbba9
Reviewed-on: https://go-review.googlesource.com/95795
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Calling UDPConn readers (Read, ReadFrom, ReadMsgUDP) to read part of
datagram returns error (in Windows), mentioning there is more data
available, and 0 as size of read data, even though part of data is
already read.

This fix makes UDPConn readers to return truncated payload size,
even there is error due more data available to read.

Fixes #14074
Updates #18056

Change-Id: Id7eec7f544dd759b2d970fa2561eef2937ec4662
Reviewed-on: https://go-review.googlesource.com/92475
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

For now, limited to the most repetitive rules that are also short and
simple, so that we can have a substantial conciseness win without
compromising rules readability.

Ran rulegen, no change in the actual compiler code (as expected).

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

GitHub-Last-Rev: ff68319f4c46271ddb927d176756962a3a2b4332
GitHub-Pull-Request: golang/go#23874
Change-Id: I7242c5cc35f04e23d807f5e91180c4ef510e7d1a
Reviewed-on: https://go-review.googlesource.com/94840Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

We don't want to account the memory for mheap_.arenas because most of
it is never touched, so currently we pass the address of a uint64 on
the heap. However, at least on mips, it's possible for this uint64 to
be unaligned, which causes the atomic add in mSysStatInc to crash.

Fix this by instead passing a nil stat pointer.

Fixes #23946.

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

+ Move from Markdown checklist to text. The first PR comment is
  presented as text when creating it.
+ Add the note about Signed-Off-By: not being required.

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

Currently zip benchmarks spend 60% in the rleBuffer code,
which is used only to test zip archive/zip itself:
    17.48s 37.02% 37.02%     18.12s 38.37%  archive/zip.(*rleBuffer).ReadAt
     9.51s 20.14% 57.16%     10.43s 22.09%  archive/zip.(*rleBuffer).Write
     9.15s 19.38% 76.54%     10.85s 22.98%  compress/flate.(*compressor).deflate

This means that benchmarks currently test performance of test helper.
Updating ReadAt/Write methods to be more performant makes benchmarks closer to real world.

name                       old time/op    new time/op    delta
CompressedZipGarbage-8       2.34ms ± 0%    2.34ms ± 1%     ~     (p=0.684 n=10+10)
Zip64Test-8                  58.1ms ± 2%    10.7ms ± 1%  -81.54%  (p=0.000 n=10+10)
Zip64TestSizes/4096-8        4.05µs ± 2%    3.65µs ± 5%   -9.96%  (p=0.000 n=9+10)
Zip64TestSizes/1048576-8      238µs ± 0%      43µs ± 0%  -82.06%  (p=0.000 n=10+10)
Zip64TestSizes/67108864-8    15.3ms ± 1%     2.6ms ± 0%  -83.12%  (p=0.000 n=10+9)

name                       old alloc/op   new alloc/op   delta
CompressedZipGarbage-8       17.9kB ±14%    16.0kB ±24%  -10.48%  (p=0.026 n=9+10)

name                       old allocs/op  new allocs/op  delta
CompressedZipGarbage-8         44.0 ± 0%      44.0 ± 0%     ~     (all equal)

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

reflect.unsafe_New is an often called function according
to profiling in a large production environment.

Since newobject is not inlined currently there
is call overhead that can be avoided by calling
mallocgc directly.

name  old time/op  new time/op  delta
New   32.4ns ± 2%  29.8ns ± 1%  -8.03%  (p=0.000 n=19+20)

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

Similar to https://golang.org/cl/54391, but for sha512
name          old time/op    new time/op    delta
Hash8Bytes-8     289ns ± 1%     253ns ± 2%  -12.59%  (p=0.000 n=10+10)
Hash1K-8        1.85µs ± 1%    1.82µs ± 1%   -1.77%  (p=0.000 n=9+10)
Hash8K-8        12.7µs ± 2%    12.5µs ± 1%     ~     (p=0.075 n=10+10)

name          old speed      new speed      delta
Hash8Bytes-8  27.6MB/s ± 1%  31.6MB/s ± 2%  +14.43%  (p=0.000 n=10+10)
Hash1K-8       554MB/s ± 1%   564MB/s ± 1%   +1.81%  (p=0.000 n=9+10)
Hash8K-8       647MB/s ± 2%   653MB/s ± 1%     ~     (p=0.075 n=10+10)

Change-Id: I437668c96ad55f8dbb62c89c8fc3f433453b5330
Reviewed-on: https://go-review.googlesource.com/82996
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>

Similar to https://golang.org/cl/54391, but for sha256
name          old time/op    new time/op    delta
Hash8Bytes-8     209ns ± 1%     191ns ± 1%  -8.65%  (p=0.000 n=10+9)
Hash1K-8        2.49µs ± 1%    2.47µs ± 2%  -0.74%  (p=0.045 n=9+10)
Hash8K-8        18.4µs ± 1%    18.2µs ± 0%  -0.98%  (p=0.009 n=10+10)

name          old speed      new speed      delta
Hash8Bytes-8  38.1MB/s ± 1%  41.8MB/s ± 1%  +9.47%  (p=0.000 n=10+9)
Hash1K-8       412MB/s ± 1%   415MB/s ± 2%    ~     (p=0.051 n=9+10)
Hash8K-8       445MB/s ± 1%   450MB/s ± 0%  +0.98%  (p=0.009 n=10+10)

Change-Id: I50ca80fc28c279fbb758b7c849f67d8c66391eb6
Reviewed-on: https://go-review.googlesource.com/82995
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>

For functions with many local variables, keeping track of every
LocalSlot for every variable is very expensive. Only track the slots
that are actually used by a given variable.

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

Keeping the start state of each block around costs more than just
recomputing them as necessary, especially because many blocks only have
one predecessor and don't need any merging at all. Stop storing the
start state, and reuse predecessors' end states as much as conveniently
possible.

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

This saves an instruction and a register. The new rules
match ~4900 times during all.bash.

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

GitHub-Last-Rev: 468df242d07419c228656985702325aa78952d99
GitHub-Pull-Request: golang/go#23935
Change-Id: If751ce3ffa3a4d5e00a3138211383d12cb6b23fc
Reviewed-on: https://go-review.googlesource.com/95577
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

For now, limited to the most repetitive rules that are also short and
simple, so that we can have a substantial conciseness win without
compromising rules readability.

Ran rulegen, no change in the actual compiler code (as expected).

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

For now, limited to a few repetitive boolean rules where the win is
substantial (4+ variants).

Change-Id: I67bce0d356ca7d71a0f15ff98551fe2caff8abf9
Reviewed-on: https://go-review.googlesource.com/95535
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

No functional changes.

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

No functional changes.

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

R=go1.11

Change-Id: Ibb09e309c745eba811a0b53000c063bc10a055e1
Reviewed-on: https://go-review.googlesource.com/90218
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>

R=go1.11

Change-Id: I2d2db148fed96d0fcb228bee414b050fe4e46e2c
Reviewed-on: https://go-review.googlesource.com/90217Reviewed-by: Heschi Kreinick <heschi@google.com>

R=go1.11

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

This adds the ability to add a #x:y anchor to the trace view URL that
causes the viewer to initially select from x ms to y ms.

Change-Id: I4a980d8128ecc85dbe41f224e8ae336707a4eaab
Reviewed-on: https://go-review.googlesource.com/60794
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

In addition to look nicer to the eye, this allows to reformat
and indent rules without causing spurious changes to the generated
file, making it easier to spot functional changes.

After this CL, all CLs that will aggregate rules through
the new "|" functionality should cause no changes to the
generated files.

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

Replace some ints with bool and use arrays istead of slices where
possible.

Change-Id: I510bdaec48f9c437685e72c4a3291cffeb7ef5fc
Reviewed-on: https://go-review.googlesource.com/83859
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ia5908e94a6bd362099ca3c63f6ffb7e94457131d
GitHub-Last-Rev: 545a40571a912f433546d8c94a9d63459313515d
GitHub-Pull-Request: golang/go#23942
Reviewed-on: https://go-review.googlesource.com/95435Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The code was maintaining manual versions of it in multiple places -
replace all of them.

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

This follows up CL95235

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

Using stringer.

Fixes #22684.

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

A pair of MUL/NEG instructions can be combined to a single MNEG on ARM64.
This CL implements this optimization.

1. A special test case gets big improvement.
(https://github.com/benshi001/ugo1/blob/master/mneg_test.go)
name                     old time/op    new time/op    delta
MNEG-4                      315µs ± 0%     260µs ± 0%  -17.39%  (p=0.000 n=24+25)

2. There is little change in the go1 benchmark, excluding noise.
name                     old time/op    new time/op    delta
BinaryTree17-4              42.2s ± 2%     41.9s ± 2%  -0.82%  (p=0.001 n=30+26)
Fannkuch11-4                32.9s ± 0%     32.9s ± 0%  -0.01%  (p=0.006 n=20+26)
FmtFprintfEmpty-4           541ns ± 3%     534ns ± 0%  -1.24%  (p=0.003 n=30+26)
FmtFprintfString-4         1.09µs ± 0%    1.10µs ± 3%    ~     (p=0.142 n=23+30)
FmtFprintfInt-4            1.14µs ± 0%    1.14µs ± 0%    ~     (p=0.435 n=24+24)
FmtFprintfIntInt-4         1.76µs ± 0%    1.76µs ± 0%    ~     (p=0.508 n=24+26)
FmtFprintfPrefixedInt-4    2.20µs ± 3%    2.17µs ± 0%  -1.10%  (p=0.017 n=30+24)
FmtFprintfFloat-4          3.28µs ± 0%    3.28µs ± 0%    ~     (p=0.579 n=24+24)
FmtManyArgs-4              7.30µs ± 0%    7.30µs ± 0%    ~     (p=0.662 n=26+27)
GobDecode-4                94.8ms ± 0%    94.8ms ± 0%  +0.07%  (p=0.010 n=25+23)
GobEncode-4                80.9ms ± 4%    80.6ms ± 4%    ~     (p=0.901 n=30+30)
Gzip-4                      4.45s ± 0%     4.49s ± 0%  +0.98%  (p=0.000 n=25+24)
Gunzip-4                    450ms ± 3%     443ms ± 0%    ~     (p=0.942 n=30+26)
HTTPClientServer-4          548µs ± 1%     551µs ± 1%  +0.60%  (p=0.000 n=29+30)
JSONEncode-4                210ms ± 0%     211ms ± 0%  +0.03%  (p=0.000 n=23+25)
JSONDecode-4                866ms ± 5%     877ms ± 5%    ~     (p=0.187 n=30+30)
Mandelbrot200-4            51.4ms ± 0%    52.0ms ± 3%  +1.15%  (p=0.001 n=24+30)
GoParse-4                  42.9ms ± 5%    41.9ms ± 0%  -2.24%  (p=0.000 n=30+26)
RegexpMatchEasy0_32-4      1.02µs ± 3%    1.01µs ± 0%    ~     (p=0.247 n=30+26)
RegexpMatchEasy0_1K-4      3.90µs ± 0%    3.90µs ± 0%    ~     (p=0.062 n=24+24)
RegexpMatchEasy1_32-4       955ns ± 0%     956ns ± 0%  +0.16%  (p=0.000 n=25+23)
RegexpMatchEasy1_1K-4      6.42µs ± 3%    6.37µs ± 0%  -0.81%  (p=0.012 n=30+24)
RegexpMatchMedium_32-4     1.77µs ± 3%    1.79µs ± 0%  +1.28%  (p=0.003 n=30+24)
RegexpMatchMedium_1K-4      561µs ± 0%     569µs ± 3%  +1.50%  (p=0.000 n=25+30)
RegexpMatchHard_32-4       31.0µs ± 4%    30.8µs ± 0%    ~     (p=1.000 n=26+26)
RegexpMatchHard_1K-4        945µs ± 3%     945µs ± 3%    ~     (p=0.513 n=30+30)
Revcomp-4                   7.76s ± 4%     7.68s ± 0%    ~     (p=0.464 n=29+23)
Template-4                  903ms ± 5%     904ms ± 5%    ~     (p=0.248 n=30+30)
TimeParse-4                4.80µs ± 0%    4.80µs ± 0%    ~     (p=0.081 n=25+26)
TimeFormat-4               4.70µs ± 1%    4.70µs ± 1%    ~     (p=0.763 n=24+26)
[Geo mean]                  709µs          708µs       -0.09%

name                     old speed      new speed      delta
GobDecode-4              8.10MB/s ± 0%  8.09MB/s ± 0%    ~     (p=0.160 n=25+23)
GobEncode-4              9.49MB/s ± 4%  9.53MB/s ± 4%    ~     (p=0.360 n=30+30)
Gzip-4                   4.36MB/s ± 0%  4.32MB/s ± 0%  -0.92%  (p=0.000 n=25+24)
Gunzip-4                 43.2MB/s ± 3%  43.8MB/s ± 0%    ~     (p=0.980 n=30+26)
JSONEncode-4             9.22MB/s ± 0%  9.22MB/s ± 0%  -0.04%  (p=0.005 n=23+25)
JSONDecode-4             2.24MB/s ± 5%  2.21MB/s ± 4%    ~     (p=0.252 n=30+30)
GoParse-4                1.35MB/s ± 5%  1.38MB/s ± 0%  +2.00%  (p=0.003 n=30+26)
RegexpMatchEasy0_32-4    31.5MB/s ± 3%  31.8MB/s ± 0%    ~     (p=0.110 n=30+26)
RegexpMatchEasy0_1K-4     263MB/s ± 0%   263MB/s ± 0%    ~     (p=0.111 n=24+24)
RegexpMatchEasy1_32-4    33.5MB/s ± 0%  33.4MB/s ± 0%  -0.16%  (p=0.003 n=25+23)
RegexpMatchEasy1_1K-4     160MB/s ± 3%   161MB/s ± 0%  +0.78%  (p=0.012 n=30+24)
RegexpMatchMedium_32-4    565kB/s ± 3%   560kB/s ± 0%  -0.83%  (p=0.001 n=30+24)
RegexpMatchMedium_1K-4   1.83MB/s ± 0%  1.80MB/s ± 3%  -1.56%  (p=0.000 n=25+30)
RegexpMatchHard_32-4     1.03MB/s ± 3%  1.04MB/s ± 0%  +1.46%  (p=0.000 n=30+26)
RegexpMatchHard_1K-4     1.08MB/s ± 3%  1.09MB/s ± 3%    ~     (p=0.444 n=30+30)
Revcomp-4                32.8MB/s ± 4%  33.1MB/s ± 0%    ~     (p=0.858 n=29+23)
Template-4               2.15MB/s ± 5%  2.15MB/s ± 5%    ~     (p=0.646 n=30+30)
[Geo mean]               7.79MB/s       7.81MB/s       +0.21%

3. There is no regression in the compilecmp benchmark.
name        old time/op       new time/op       delta
Template          2.35s ± 4%        2.33s ± 3%    ~     (p=0.796 n=10+10)
Unicode           1.35s ± 6%        1.35s ± 5%    ~     (p=1.000 n=9+10)
GoTypes           8.10s ± 3%        8.14s ± 3%    ~     (p=0.604 n=9+10)
Compiler          40.5s ± 2%        40.2s ± 2%    ~     (p=0.065 n=10+9)
SSA                115s ± 2%         115s ± 2%    ~     (p=0.447 n=9+10)
Flate             1.45s ± 3%        1.45s ± 4%    ~     (p=0.739 n=10+10)
GoParser          1.85s ± 3%        1.86s ± 2%    ~     (p=0.853 n=10+10)
Reflect           5.11s ± 2%        5.10s ± 2%    ~     (p=0.971 n=10+10)
Tar               2.23s ± 5%        2.23s ± 3%    ~     (p=0.796 n=10+10)
XML               2.67s ± 2%        2.69s ± 2%    ~     (p=0.549 n=9+10)
[Geo mean]        5.00s             5.00s       +0.02%

name        old user-time/op  new user-time/op  delta
Template          2.88s ± 2%        2.86s ± 2%    ~     (p=0.529 n=10+10)
Unicode           1.70s ± 7%        1.69s ± 5%    ~     (p=0.853 n=10+10)
GoTypes           9.72s ± 1%        9.73s ± 1%    ~     (p=0.684 n=10+10)
Compiler          49.0s ± 1%        48.9s ± 1%    ~     (p=0.631 n=10+10)
SSA                144s ± 1%         144s ± 2%    ~     (p=0.684 n=10+10)
Flate             1.71s ± 4%        1.72s ± 4%    ~     (p=0.853 n=10+10)
GoParser          2.23s ± 2%        2.23s ± 2%    ~     (p=0.971 n=10+10)
Reflect           5.98s ± 2%        5.96s ± 2%    ~     (p=0.481 n=10+10)
Tar               2.68s ± 3%        2.67s ± 2%    ~     (p=0.393 n=10+10)
XML               3.21s ± 3%        3.22s ± 1%    ~     (p=0.604 n=10+9)
[Geo mean]        6.05s             6.05s       -0.04%

name        old text-bytes    new text-bytes    delta
HelloSize         641kB ± 0%        641kB ± 0%    ~     (all equal)

name        old data-bytes    new data-bytes    delta
HelloSize        9.46kB ± 0%       9.46kB ± 0%    ~     (all equal)

name        old bss-bytes     new bss-bytes     delta
HelloSize         125kB ± 0%        125kB ± 0%    ~     (all equal)

name        old exe-bytes     new exe-bytes     delta
HelloSize        1.24MB ± 0%       1.24MB ± 0%    ~     (all equal)

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

On Plan 9, the underlying create() syscall with DMDIR flag, which is
used to implement Mkdir, will fail silently if the path exists and
is not a directory.  Work around this by checking for existence
first and rejecting Mkdir with error EEXIST if the path is found.

Fixes #23918

Change-Id: I439115662307923c9f498d3e7b1f32c6d205e1ad
Reviewed-on: https://go-review.googlesource.com/94777Reviewed-by: David du Colombier <0intro@gmail.com>

We live in the era of virtualization and isolation.
There is no reason to hesitate to use IPv4 loopback address block for
umbrella-type customer accommodating services.

Fixes #23903

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