1
0
mirror of https://github.com/golang/go synced 2024-11-06 03:26:15 -07:00
Commit Graph

41244 Commits

Author SHA1 Message Date
Cherry Zhang
1abe22c3c1 cmd/compile: don't mark stack object symbol DUPOK
Stack object symbol is named as <FunctionName>.stkobj. If the
function itself is not DUPOK, its stack object symbol should only
be defined in the package where the function is defined,
therefore no duplicates.

If in the future we change the stack object symbol to
content-hash naming, as other gcdata symbols, we can mark it as
DUPOK.

Change-Id: I5aee96578940e2f76e7115d96cd2716021672c03
Reviewed-on: https://go-review.googlesource.com/c/go/+/191437
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-28 15:05:12 +00:00
Daniel Martí
81fde0c941 net/http: fix a long test after CL 185117
The net/url error in question now quotes the URL, so update the expected
output string.

While at it, also update a comment in httputil, though that doesn't
affect any test.

Fixes #33910.

Change-Id: I0981f528b24337c2952ef60c0db3b7ff72d72110
Reviewed-on: https://go-review.googlesource.com/c/go/+/192078
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28 14:02:41 +00:00
Bryan C. Mills
372b0eed17 Revert "cmd/compile: optimize 386's math.bits.TrailingZeros16"
This reverts CL 189277.

Reason for revert: broke 32-bit builders.

Updates #33902

Change-Id: Ie5f180d0371a90e5057ed578c334372e5fc3a286
Reviewed-on: https://go-review.googlesource.com/c/go/+/192097
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2019-08-28 12:57:59 +00:00
Nao YONASHIRO
bc92fe8b34 compress/flate: improve deflate performance by register allocating the index
Use local index variable to help the go compiler use a
register to for the hash index instead of continuous
memory read and write operations.

compress/flate:
Encode/Digits/Huffman/1e4-4        35.3µs ± 1%    32.7µs ± 0%  -7.48%  (p=0.000 n=17+19)
Encode/Digits/Huffman/1e5-4         330µs ± 0%     312µs ± 0%  -5.55%  (p=0.000 n=17+18)
Encode/Digits/Huffman/1e6-4        3.30ms ± 0%    3.12ms ± 0%  -5.64%  (p=0.000 n=18+19)
Encode/Digits/Speed/1e4-4           157µs ± 0%     156µs ± 0%  -0.41%  (p=0.000 n=17+19)
Encode/Digits/Speed/1e5-4          1.46ms ± 0%    1.46ms ± 1%    ~     (p=0.478 n=20+19)
Encode/Digits/Speed/1e6-4          14.4ms ± 0%    14.4ms ± 0%    ~     (p=0.835 n=19+20)
Encode/Digits/Default/1e4-4         309µs ± 0%     310µs ± 0%  +0.23%  (p=0.000 n=19+17)
Encode/Digits/Default/1e5-4        4.76ms ± 0%    4.76ms ± 0%    ~     (p=0.297 n=19+19)
Encode/Digits/Default/1e6-4        51.0ms ± 0%    51.0ms ± 1%    ~     (p=0.233 n=18+19)
Encode/Digits/Compression/1e4-4     309µs ± 0%     310µs ± 0%  +0.21%  (p=0.000 n=17+20)
Encode/Digits/Compression/1e5-4    4.76ms ± 0%    4.76ms ± 0%    ~     (p=0.749 n=20+19)
Encode/Digits/Compression/1e6-4    50.9ms ± 0%    50.9ms ± 0%    ~     (p=0.499 n=18+19)
Encode/Newton/Huffman/1e4-4        51.9µs ± 0%    48.0µs ± 0%  -7.61%  (p=0.000 n=19+19)
Encode/Newton/Huffman/1e5-4         396µs ± 0%     377µs ± 0%  -4.79%  (p=0.000 n=18+19)
Encode/Newton/Huffman/1e6-4        3.95ms ± 0%    3.74ms ± 0%  -5.21%  (p=0.000 n=20+17)
Encode/Newton/Speed/1e4-4           155µs ± 0%     154µs ± 0%  -0.67%  (p=0.000 n=17+18)
Encode/Newton/Speed/1e5-4          1.17ms ± 0%    1.16ms ± 0%  -0.64%  (p=0.000 n=20+16)
Encode/Newton/Speed/1e6-4          11.6ms ± 0%    11.5ms ± 0%  -0.63%  (p=0.000 n=19+20)
Encode/Newton/Default/1e4-4         347µs ± 0%     347µs ± 0%    ~     (p=0.744 n=20+19)
Encode/Newton/Default/1e5-4        5.06ms ± 0%    5.02ms ± 0%  -0.77%  (p=0.000 n=20+19)
Encode/Newton/Default/1e6-4        53.3ms ± 1%    52.8ms ± 0%  -0.91%  (p=0.000 n=18+16)
Encode/Newton/Compression/1e4-4     351µs ± 0%     351µs ± 0%    ~     (p=0.277 n=20+20)
Encode/Newton/Compression/1e5-4    6.90ms ± 0%    6.85ms ± 0%  -0.61%  (p=0.000 n=19+18)
Encode/Newton/Compression/1e6-4    73.2ms ± 0%    72.8ms ± 0%  -0.52%  (p=0.000 n=18+18)

name                             old speed      new speed      delta
Encode/Digits/Huffman/1e4-4       283MB/s ± 1%   306MB/s ± 0%  +8.09%  (p=0.000 n=17+19)
Encode/Digits/Huffman/1e5-4       303MB/s ± 0%   321MB/s ± 0%  +5.87%  (p=0.000 n=18+18)
Encode/Digits/Huffman/1e6-4       303MB/s ± 0%   321MB/s ± 0%  +5.98%  (p=0.000 n=18+19)
Encode/Digits/Speed/1e4-4        63.9MB/s ± 0%  64.2MB/s ± 0%  +0.41%  (p=0.000 n=17+19)
Encode/Digits/Speed/1e5-4        68.5MB/s ± 0%  68.4MB/s ± 1%    ~     (p=0.481 n=20+19)
Encode/Digits/Speed/1e6-4        69.4MB/s ± 0%  69.3MB/s ± 0%    ~     (p=0.712 n=19+20)
Encode/Digits/Default/1e4-4      32.3MB/s ± 0%  32.3MB/s ± 0%  -0.23%  (p=0.000 n=19+17)
Encode/Digits/Default/1e5-4      21.0MB/s ± 0%  21.0MB/s ± 0%    ~     (p=0.460 n=19+19)
Encode/Digits/Default/1e6-4      19.6MB/s ± 0%  19.6MB/s ± 1%    ~     (p=0.180 n=18+19)
Encode/Digits/Compression/1e4-4  32.3MB/s ± 0%  32.3MB/s ± 0%  -0.21%  (p=0.000 n=17+20)
Encode/Digits/Compression/1e5-4  21.0MB/s ± 0%  21.0MB/s ± 0%    ~     (p=0.700 n=20+19)
Encode/Digits/Compression/1e6-4  19.6MB/s ± 0%  19.6MB/s ± 0%    ~     (p=0.486 n=18+19)
Encode/Newton/Huffman/1e4-4       193MB/s ± 0%   208MB/s ± 0%  +8.23%  (p=0.000 n=19+19)
Encode/Newton/Huffman/1e5-4       252MB/s ± 0%   265MB/s ± 0%  +5.04%  (p=0.000 n=18+19)
Encode/Newton/Huffman/1e6-4       253MB/s ± 0%   267MB/s ± 0%  +5.49%  (p=0.000 n=20+17)
Encode/Newton/Speed/1e4-4        64.5MB/s ± 0%  65.0MB/s ± 0%  +0.67%  (p=0.000 n=17+18)
Encode/Newton/Speed/1e5-4        85.7MB/s ± 0%  86.3MB/s ± 0%  +0.65%  (p=0.000 n=20+16)
Encode/Newton/Speed/1e6-4        86.2MB/s ± 0%  86.7MB/s ± 0%  +0.63%  (p=0.000 n=19+20)
Encode/Newton/Default/1e4-4      28.9MB/s ± 0%  28.9MB/s ± 0%    ~     (p=0.840 n=20+19)
Encode/Newton/Default/1e5-4      19.8MB/s ± 0%  19.9MB/s ± 0%  +0.78%  (p=0.000 n=20+19)
Encode/Newton/Default/1e6-4      18.8MB/s ± 1%  18.9MB/s ± 0%  +0.93%  (p=0.000 n=18+16)
Encode/Newton/Compression/1e4-4  28.5MB/s ± 0%  28.5MB/s ± 0%    ~     (p=0.244 n=20+20)
Encode/Newton/Compression/1e5-4  14.5MB/s ± 0%  14.6MB/s ± 0%  +0.61%  (p=0.000 n=19+18)
Encode/Newton/Compression/1e6-4  13.7MB/s ± 0%  13.7MB/s ± 0%  +0.53%  (p=0.000 n=18+18)

image/png:
name                        old time/op    new time/op    delta
EncodeGray-4                  2.16ms ± 1%    1.85ms ± 1%  -14.17%  (p=0.000 n=86+91)
EncodeGrayWithBufferPool-4    1.99ms ± 0%    1.69ms ± 0%  -15.09%  (p=0.000 n=97+94)
EncodeNRGBOpaque-4            6.51ms ± 1%    5.62ms ± 1%  -13.66%  (p=0.000 n=90+92)
EncodeNRGBA-4                 7.33ms ± 1%    6.12ms ± 1%  -16.49%  (p=0.000 n=89+90)
EncodePaletted-4              5.10ms ± 1%    4.96ms ± 1%   -2.76%  (p=0.000 n=90+87)
EncodeRGBOpaque-4             6.51ms ± 1%    5.63ms ± 1%  -13.49%  (p=0.000 n=94+87)
EncodeRGBA-4                  24.3ms ± 2%    23.0ms ± 0%   -5.23%  (p=0.000 n=91+89)

name                        old speed      new speed      delta
EncodeGray-4                 142MB/s ± 1%   166MB/s ± 1%  +16.50%  (p=0.000 n=86+91)
EncodeGrayWithBufferPool-4   154MB/s ± 0%   182MB/s ± 0%  +17.78%  (p=0.000 n=97+94)
EncodeNRGBOpaque-4           189MB/s ± 1%   219MB/s ± 1%  +15.82%  (p=0.000 n=90+93)
EncodeNRGBA-4                168MB/s ± 1%   201MB/s ± 1%  +19.75%  (p=0.000 n=89+90)
EncodePaletted-4            60.3MB/s ± 1%  62.0MB/s ± 1%   +2.84%  (p=0.000 n=90+87)
EncodeRGBOpaque-4            189MB/s ± 1%   218MB/s ± 1%  +15.60%  (p=0.000 n=94+87)
EncodeRGBA-4                50.6MB/s ± 2%  53.4MB/s ± 0%   +5.51%  (p=0.000 n=91+89)

Change-Id: Ifed4486a7ba19a26abe5cbf2142f15cc7464e84f
Reviewed-on: https://go-review.googlesource.com/c/go/+/187837
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-08-28 12:48:37 +00:00
Stefan Baebler
64cfe9fe22 net/url: improve url parsing error messages by quoting
Current implementation doesn't always make it obvious what the exact
problem with the URL is, so this makes it clearer by consistently quoting
the invalid URL, as is the norm in other parsing implementations, eg.:
strconv.Atoi(" 123") returns an error: parsing " 123": invalid syntax

Updates #29261

Change-Id: Icc6bff8b4a4584677c0f769992823e6e1e0d397d
GitHub-Last-Rev: 648b9d93fe
GitHub-Pull-Request: golang/go#29384
Reviewed-on: https://go-review.googlesource.com/c/go/+/185117
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28 12:47:06 +00:00
Martin Möhrmann
5fb74fc138 runtime: reduce allocations when building pprof LabelSet
Pre-allocate the slice of labels with enough capacity
to avoid growslice calls.

Change-Id: I89db59ac722c03b0202e042d1f707bb041e0999f
Reviewed-on: https://go-review.googlesource.com/c/go/+/181517
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
2019-08-28 10:43:11 +00:00
Eddie Scholtz
37373592af encoding/xml: rename fInnerXml to fInnerXML
Per the code review guidelines: "Words in names that are
initialisms or acronyms have a consistent case."

Change-Id: I347b02d2f48455f2cbbc040191ba197e3e8f23fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/191970
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28 10:21:40 +00:00
Martin Möhrmann
5ff12f6269 net/url: use strings.IndexByte instead of strings.Index in split function
Production profiling shows ~15% of url.Parse time being spend in the overhead
of calling strings.IndexByte through strings.Index instead of calling
strings.IndexByte directly.

name   old time/op  new time/op  delta
Split  15.5ns ± 2%  10.7ns ± 3%  -30.98%  (p=0.000 n=20+19)

Change-Id: Ie25dd4afa93539a1335a91ab2a4a367f97bd3df0
Reviewed-on: https://go-review.googlesource.com/c/go/+/178877
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-28 10:04:01 +00:00
Cuong Manh Le
6a73e94c10 cmd/compile: remove gc.eqtype in comments
golang.org/cl/143180 changed gc.eqtype to types.Identical, but gc.eqtype
is still mentioned in some comments. Remove them and update comments to
mention new functions instead.

Change-Id: I6c5eece5221f524556ee55db80de0e4bdfaf166e
Reviewed-on: https://go-review.googlesource.com/c/go/+/191357
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2019-08-28 09:28:59 +00:00
Nao YONASHIRO
f04f594a1f image/png: hoist repetitive pixels per byte out of loop in Encode
The existing implementation has calculated pixels per byte for each pixel.
reduce the calculation of pixels per byte.

name                        old time/op    new time/op     delta
EncodeGray-4                  2.16ms ± 1%     2.16ms ± 1%    -0.28%  (p=0.000 n=86+84)
EncodeGrayWithBufferPool-4    1.99ms ± 0%     1.97ms ± 0%    -0.72%  (p=0.000 n=97+92)
EncodeNRGBOpaque-4            6.51ms ± 1%     6.48ms ± 1%    -0.45%  (p=0.000 n=90+85)
EncodeNRGBA-4                 7.33ms ± 1%     7.28ms ± 0%    -0.69%  (p=0.000 n=89+87)
EncodePaletted-4              5.10ms ± 1%     2.29ms ± 0%   -55.11%  (p=0.000 n=90+85)
EncodeRGBOpaque-4             6.51ms ± 1%     6.51ms ± 0%      ~     (p=0.311 n=94+88)
EncodeRGBA-4                  24.3ms ± 2%     24.1ms ± 1%    -0.87%  (p=0.000 n=91+91)

name                        old speed      new speed       delta
EncodeGray-4                 142MB/s ± 1%    143MB/s ± 1%    +0.26%  (p=0.000 n=86+85)
EncodeGrayWithBufferPool-4   154MB/s ± 0%    156MB/s ± 0%    +0.73%  (p=0.000 n=97+92)
EncodeNRGBOpaque-4           189MB/s ± 1%    190MB/s ± 1%    +0.44%  (p=0.000 n=90+86)
EncodeNRGBA-4                168MB/s ± 1%    169MB/s ± 0%    +0.69%  (p=0.000 n=89+87)
EncodePaletted-4            60.3MB/s ± 1%  134.2MB/s ± 0%  +122.74%  (p=0.000 n=90+85)
EncodeRGBOpaque-4            189MB/s ± 1%    189MB/s ± 0%      ~     (p=0.326 n=94+88)
EncodeRGBA-4                50.6MB/s ± 2%   51.1MB/s ± 1%    +0.87%  (p=0.000 n=91+91)

name                        old alloc/op   new alloc/op    delta
EncodeGray-4                   852kB ± 0%      852kB ± 0%    +0.00%  (p=0.000 n=100+100)
EncodeGrayWithBufferPool-4    1.49kB ± 2%     1.47kB ± 1%    -0.88%  (p=0.000 n=95+90)
EncodeNRGBOpaque-4             860kB ± 0%      860kB ± 0%    +0.00%  (p=0.003 n=98+58)
EncodeNRGBA-4                  864kB ± 0%      864kB ± 0%    +0.00%  (p=0.021 n=100+99)
EncodePaletted-4               849kB ± 0%      849kB ± 0%    +0.00%  (p=0.040 n=100+100)
EncodeRGBOpaque-4              860kB ± 0%      860kB ± 0%      ~     (p=0.062 n=66+98)
EncodeRGBA-4                  3.32MB ± 0%     3.32MB ± 0%    -0.00%  (p=0.044 n=99+99)

name                        old allocs/op  new allocs/op   delta
EncodeGray-4                    32.0 ± 0%       32.0 ± 0%      ~     (all equal)
EncodeGrayWithBufferPool-4      3.00 ± 0%       3.00 ± 0%      ~     (all equal)
EncodeNRGBOpaque-4              32.0 ± 0%       32.0 ± 0%      ~     (all equal)
EncodeNRGBA-4                   32.0 ± 0%       32.0 ± 0%      ~     (all equal)
EncodePaletted-4                36.0 ± 0%       36.0 ± 0%      ~     (all equal)
EncodeRGBOpaque-4               32.0 ± 0%       32.0 ± 0%      ~     (all equal)
EncodeRGBA-4                    614k ± 0%       614k ± 0%      ~     (all equal)

Change-Id: I716bde2dc80d8111d75d3d765fc09223f770d5a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/187417
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28 09:02:35 +00:00
Agniva De Sarker
7be97af2ff cmd/compile: apply optimization for readonly globals on wasm
Extend the optimization introduced in CL 141118 to the wasm architecture.

And for reference, the rules trigger 212 times while building std and cmd

$GOOS=js GOARCH=wasm gotip build std cmd
$grep -E "Wasm.rules:44(1|2|3|4)" rulelog | wc -l
212

Updates #26498

Change-Id: I153684a2b98589ae812b42268da08b65679e09d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/185477
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
2019-08-28 05:55:52 +00:00
Agniva De Sarker
07f0460737 runtime,syscall/js: reuse wasm memory DataView
Currently, every call to mem() incurs a new DataView object. This was necessary
because the wasm linear memory could grow at any time.

Now, whenever the memory grows, we make a call to the front-end. This allows us to
reuse the existing DataView object and create a new one only when the memory actually grows.

This gives us a boost in performance during DOM operations, while incurring an extra
trip to front-end when memory grows. However, since the GrowMemory calls are meant to decrease
over the runtime of an application, this is a good tradeoff in the long run.

The benchmarks have been tested inside a browser (Google Chrome 75.0.3770.90 (Official Build) (64-bit)).
It is hard to get stable nos. for DOM operations since the jumps make the timing very unreliable.
But overall, it shows a clear gain.

name  old time/op  new time/op  delta
DOM    135µs ±26%    84µs ±10%  -37.22%  (p=0.000 n=10+9)

Go1 benchmarks do not show any noticeable degradation:
name                   old time/op    new time/op    delta
BinaryTree17              22.5s ± 0%     22.5s ± 0%     ~     (p=0.743 n=8+9)
Fannkuch11                15.1s ± 0%     15.1s ± 0%   +0.17%  (p=0.000 n=9+9)
FmtFprintfEmpty           324ns ± 1%     303ns ± 0%   -6.64%  (p=0.000 n=9+10)
FmtFprintfString          535ns ± 1%     515ns ± 0%   -3.85%  (p=0.000 n=10+10)
FmtFprintfInt             609ns ± 0%     589ns ± 0%   -3.28%  (p=0.000 n=10+10)
FmtFprintfIntInt          938ns ± 0%     920ns ± 0%   -1.92%  (p=0.000 n=9+10)
FmtFprintfPrefixedInt     950ns ± 0%     924ns ± 0%   -2.72%  (p=0.000 n=10+9)
FmtFprintfFloat          1.41µs ± 1%    1.43µs ± 0%   +1.01%  (p=0.000 n=10+10)
FmtManyArgs              3.66µs ± 1%    3.46µs ± 0%   -5.43%  (p=0.000 n=9+10)
GobDecode                38.8ms ± 1%    37.8ms ± 0%   -2.50%  (p=0.000 n=10+8)
GobEncode                26.3ms ± 1%    26.3ms ± 0%     ~     (p=0.853 n=10+10)
Gzip                      1.16s ± 1%     1.16s ± 0%   -0.37%  (p=0.008 n=10+9)
Gunzip                    210ms ± 0%     208ms ± 1%   -1.01%  (p=0.000 n=10+10)
JSONEncode               48.0ms ± 0%    48.1ms ± 1%   +0.29%  (p=0.019 n=9+9)
JSONDecode                348ms ± 1%     326ms ± 1%   -6.34%  (p=0.000 n=10+10)
Mandelbrot200            6.62ms ± 0%    6.64ms ± 0%   +0.37%  (p=0.000 n=7+9)
GoParse                  23.9ms ± 1%    24.7ms ± 1%   +2.98%  (p=0.000 n=9+9)
RegexpMatchEasy0_32       555ns ± 0%     561ns ± 0%   +1.10%  (p=0.000 n=8+10)
RegexpMatchEasy0_1K      3.94µs ± 1%    3.94µs ± 0%     ~     (p=0.906 n=9+8)
RegexpMatchEasy1_32       516ns ± 0%     524ns ± 0%   +1.51%  (p=0.000 n=9+10)
RegexpMatchEasy1_1K      4.39µs ± 1%    4.40µs ± 1%     ~     (p=0.171 n=10+10)
RegexpMatchMedium_32     25.1ns ± 0%    25.5ns ± 0%   +1.51%  (p=0.000 n=9+8)
RegexpMatchMedium_1K      196µs ± 0%     203µs ± 1%   +3.23%  (p=0.000 n=9+10)
RegexpMatchHard_32       11.2µs ± 1%    11.6µs ± 1%   +3.62%  (p=0.000 n=10+10)
RegexpMatchHard_1K        334µs ± 1%     348µs ± 1%   +4.21%  (p=0.000 n=9+10)
Revcomp                   2.39s ± 0%     2.41s ± 0%   +0.78%  (p=0.000 n=8+9)
Template                  385ms ± 1%     336ms ± 0%  -12.61%  (p=0.000 n=10+9)
TimeParse                2.18µs ± 1%    2.18µs ± 1%     ~     (p=0.424 n=10+10)
TimeFormat               2.28µs ± 1%    2.22µs ± 1%   -2.30%  (p=0.000 n=10+10)

name                   old speed      new speed      delta
GobDecode              19.8MB/s ± 1%  20.3MB/s ± 0%   +2.56%  (p=0.000 n=10+8)
GobEncode              29.1MB/s ± 1%  29.2MB/s ± 0%     ~     (p=0.810 n=10+10)
Gzip                   16.7MB/s ± 1%  16.8MB/s ± 0%   +0.37%  (p=0.007 n=10+9)
Gunzip                 92.2MB/s ± 0%  93.2MB/s ± 1%   +1.03%  (p=0.000 n=10+10)
JSONEncode             40.4MB/s ± 0%  40.3MB/s ± 1%   -0.28%  (p=0.025 n=9+9)
JSONDecode             5.58MB/s ± 1%  5.96MB/s ± 1%   +6.80%  (p=0.000 n=10+10)
GoParse                2.42MB/s ± 0%  2.35MB/s ± 1%   -2.83%  (p=0.000 n=8+9)
RegexpMatchEasy0_32    57.7MB/s ± 0%  57.0MB/s ± 0%   -1.09%  (p=0.000 n=8+10)
RegexpMatchEasy0_1K     260MB/s ± 1%   260MB/s ± 0%     ~     (p=0.963 n=9+8)
RegexpMatchEasy1_32    62.1MB/s ± 0%  61.1MB/s ± 0%   -1.53%  (p=0.000 n=10+10)
RegexpMatchEasy1_1K     233MB/s ± 1%   233MB/s ± 1%     ~     (p=0.190 n=10+10)
RegexpMatchMedium_32   39.8MB/s ± 0%  39.1MB/s ± 1%   -1.74%  (p=0.000 n=9+10)
RegexpMatchMedium_1K   5.21MB/s ± 0%  5.05MB/s ± 1%   -3.09%  (p=0.000 n=9+10)
RegexpMatchHard_32     2.86MB/s ± 1%  2.76MB/s ± 1%   -3.43%  (p=0.000 n=10+10)
RegexpMatchHard_1K     3.06MB/s ± 1%  2.94MB/s ± 1%   -4.06%  (p=0.000 n=9+10)
Revcomp                 106MB/s ± 0%   105MB/s ± 0%   -0.77%  (p=0.000 n=8+9)
Template               5.04MB/s ± 1%  5.77MB/s ± 0%  +14.48%  (p=0.000 n=10+9)

Updates #32591

Change-Id: Id567e14a788e359248b2129ef1cf0adc8cc4ab7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/183457
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
2019-08-28 05:11:20 +00:00
Agniva De Sarker
e7a4ab427d net/http/httputil: fix goroutine leak for DumpRequestOut
When an invalid URL was passed to DumpRequestOut, it would directly return
without gracefully shutting down the reader goroutine.

So we create a channel and signal the reader goroutine to exit
if an error occurs during roundtrip.

Fixes #32571

Change-Id: I8c2970f1601e599f3d1ebfed298faf5f5716fc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/182037
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2019-08-28 04:44:32 +00:00
Agniva De Sarker
8fedb2d338 cmd/compile: optimize bounded shifts on wasm
Use the shiftIsBounded function to generate more efficient
Shift instructions.

Updates #25167

Change-Id: Id350f8462dc3a7ed3bfed0bcbea2860b8f40048a
Reviewed-on: https://go-review.googlesource.com/c/go/+/182558
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
2019-08-28 04:44:21 +00:00
Agniva De Sarker
b9ef4c0f56 cmd/compile: coalesce a few shift rules for wasm
Change-Id: I1b76daba90afd474390db8d9c238445abaac7ca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/182557
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-28 04:43:53 +00:00
Sam Arnold
3d48ae355b strconv: Speed improvement to number parsing
Run underscore validation only if we have seen underscores.

Some performance results on my laptop:
name                   old time/op  new time/op  delta
Atof64Decimal-12       30.5ns ± 0%  23.8ns ± 0%  -22.02%  (p=0.016 n=5+4)
Atof64Float-12         39.0ns ± 0%  28.7ns ± 0%  -26.39%  (p=0.002 n=6+6)
Atof64FloatExp-12      64.4ns ± 1%  54.4ns ± 1%  -15.65%  (p=0.002 n=6+6)
Atof64Big-12            115ns ± 1%    87ns ± 1%  -24.45%  (p=0.002 n=6+6)
Atof64RandomBits-12     187ns ±14%   156ns ±19%  -16.46%  (p=0.032 n=6+6)
Atof64RandomFloats-12   126ns ± 0%   105ns ± 1%  -16.65%  (p=0.000 n=6+5)
Atof32Decimal-12       32.0ns ± 1%  24.0ns ± 1%  -24.97%  (p=0.002 n=6+6)
Atof32Float-12         37.1ns ± 1%  27.0ns ± 1%  -27.42%  (p=0.002 n=6+6)
Atof32FloatExp-12      68.4ns ± 1%  54.2ns ± 1%  -20.77%  (p=0.002 n=6+6)
Atof32Random-12        92.0ns ± 1%  77.4ns ± 0%  -15.81%  (p=0.000 n=6+5)
ParseInt/Pos/7bit-12   19.4ns ± 1%  13.8ns ±10%  -28.94%  (p=0.002 n=6+6)
ParseInt/Pos/26bit-12  29.1ns ± 1%  19.8ns ± 2%  -31.92%  (p=0.002 n=6+6)
ParseInt/Pos/31bit-12  33.1ns ± 0%  22.3ns ± 3%  -32.62%  (p=0.004 n=5+6)
ParseInt/Pos/56bit-12  47.8ns ± 1%  30.7ns ± 1%  -35.78%  (p=0.004 n=6+5)
ParseInt/Pos/63bit-12  51.9ns ± 1%  33.4ns ± 2%  -35.49%  (p=0.002 n=6+6)
ParseInt/Neg/7bit-12   18.5ns ± 4%  13.4ns ± 3%  -27.88%  (p=0.002 n=6+6)
ParseInt/Neg/26bit-12  28.4ns ± 3%  19.7ns ± 3%  -30.38%  (p=0.002 n=6+6)
ParseInt/Neg/31bit-12  31.9ns ± 1%  21.8ns ± 2%  -31.56%  (p=0.002 n=6+6)
ParseInt/Neg/56bit-12  46.2ns ± 0%  30.6ns ± 1%  -33.73%  (p=0.004 n=5+6)
ParseInt/Neg/63bit-12  50.2ns ± 1%  33.2ns ± 1%  -33.96%  (p=0.002 n=6+6)

Fixes #33330

Change-Id: I119da66457c2fbaf6e88bb90cf56417a16df8f0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/187957
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2019-08-28 03:23:59 +00:00
Ben Shi
22355d6cd2 cmd/compile: optimize 386's math.bits.TrailingZeros16
This CL optimizes math.bits.TrailingZeros16 on 386 with
a pair of BSFL and ORL instrcutions.

The case TrailingZeros16-4 of the benchmark test in
math/bits shows big improvement.
name               old time/op  new time/op  delta
TrailingZeros16-4  1.55ns ± 1%  0.87ns ± 1%  -43.87%  (p=0.000 n=50+49)

Change-Id: Ia899975b0e46f45dcd20223b713ed632bc32740b
Reviewed-on: https://go-review.googlesource.com/c/go/+/189277
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-28 02:29:54 +00:00
Ben Shi
e1e4c499f0 test/fixedbugs: add more test cases to issue #27718
This CL add test cases for the unary FP negative
operation.

Change-Id: I54e7292ca9df05da0c2b113adefc97ee1e94c6e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/190937
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-28 02:29:42 +00:00
Ben Shi
731e6fc34e cmd/compile: generate Select on WASM
This CL performs the branchelim optimization on WASM with its
select instruction. And the total size of pkg/js_wasm decreased
about 80KB by this optimization.

Change-Id: I868eb146120a1cac5c4609c8e9ddb07e4da8a1d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/190957
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-28 02:29:25 +00:00
fanzha02
9c67516ed6 cmd/internal/obj/arm64: add support for most system registers
This patch supports the EL0 and EL1 system registers used in MRS/MSR
instructions. This patch refactors the assembler code, allowing the
assembler to read system register information from the automatically
generated sysRegEnc.go file and move existing declared system registers
to the sysRegEnc.go file.

This patch adds 431 system registers, it is worth noting that the number
of special registers is initialized to less than 1024 in the list7.go file.

This CL also adds some test cases to test the newly added system registers.

The test cases are contributed by Dianhong Xu <Dianhong.Xu@arm.com>

Change-Id: Ic09a937eaaeefe82bd08b5dd726808f8ff6cebf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/189577
Reviewed-by: Ben Shi <powerman1st@163.com>
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28 02:28:49 +00:00
Keith Randall
b91b3d9c31 cmd/compile: remove auxSymInt32
We never used it, might as well get rid of it.

Change-Id: I5c23c93e90173bff9ac1fc1b8ae1e2025215d6eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/191938
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-28 00:40:22 +00:00
Filippo Valsorda
a8c2e5c6ad crypto/tls: remove TLS 1.3 opt-out
Fixes #30055

Change-Id: If757c43b52fc7bf62b0afb1c720615329fb5569d
Reviewed-on: https://go-review.googlesource.com/c/go/+/191999
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 22:25:08 +00:00
Filippo Valsorda
ffcb678f47 crypto/tls: remove SSLv3 support
SSLv3 has been irreparably broken since the POODLE attack 5 years ago
and RFC 7568 (f.k.a. draft-ietf-tls-sslv3-diediedie) prohibits its use
in no uncertain terms.

As announced in the Go 1.13 release notes, remove support for it
entirely in Go 1.14.

Updates #32716

Change-Id: Id653557961d8f75f484a01e6afd2e104a4ccceaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/191976
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 22:24:05 +00:00
Josh Bleecher Snyder
52ae04fdfc cmd/compile: improve shortcircuit pass
While working on #30645, I noticed that many instances
in which the walkinrange optimization could apply
were not even being considered.

This was because of extraneous blocks in the CFG,
of the type that shortcircuit normally removes.

The change improves the shortcircuit pass to handle
most of those cases. (There are a few that can only be
reasonably detected later in compilation, after other
optimizations have been run, but not enough to be worth chasing.)

Notable changes:

* Instead of calculating live-across-blocks values, use v.Uses == 1.
  This is cheaper and more straightforward.
  v.Uses did not exist when this pass was initially written.
* Incorporate a fusePlain and loop until stable.
  This is necessary to find many of the instances.
* Allow Copy and Not wrappers around Phi values.
  This significantly increases effectiveness.
* Allow removal of all preds, creating a dead block.
  The previous pass stopped unnecessarily at one pred.
* Use phielimValue during cleanup instead of manually
  setting the op to OpCopy.

The result is marginally faster compilation and smaller code.

name        old time/op       new time/op       delta
Template          213ms ± 2%        212ms ± 2%  -0.63%  (p=0.002 n=49+48)
Unicode          90.0ms ± 2%       89.8ms ± 2%    ~     (p=0.122 n=48+48)
GoTypes           710ms ± 3%        711ms ± 2%    ~     (p=0.433 n=45+49)
Compiler          3.23s ± 2%        3.22s ± 2%    ~     (p=0.124 n=47+49)
SSA               10.0s ± 1%        10.0s ± 1%  -0.43%  (p=0.000 n=48+50)
Flate             135ms ± 3%        135ms ± 2%    ~     (p=0.311 n=49+49)
GoParser          158ms ± 2%        158ms ± 2%    ~     (p=0.757 n=48+48)
Reflect           447ms ± 2%        447ms ± 2%    ~     (p=0.815 n=49+48)
Tar               189ms ± 2%        189ms ± 3%    ~     (p=0.530 n=47+49)
XML               251ms ± 3%        250ms ± 1%  -0.75%  (p=0.002 n=49+48)
[Geo mean]        427ms             426ms       -0.25%

name        old user-time/op  new user-time/op  delta
Template          265ms ± 2%        265ms ± 2%    ~     (p=0.969 n=48+50)
Unicode           119ms ± 6%        119ms ± 6%    ~     (p=0.738 n=50+50)
GoTypes           923ms ± 2%        925ms ± 2%    ~     (p=0.057 n=43+47)
Compiler          4.37s ± 2%        4.37s ± 2%    ~     (p=0.691 n=50+46)
SSA               13.4s ± 1%        13.4s ± 1%    ~     (p=0.282 n=42+49)
Flate             162ms ± 2%        162ms ± 2%    ~     (p=0.774 n=48+50)
GoParser          186ms ± 2%        186ms ± 3%    ~     (p=0.213 n=47+47)
Reflect           572ms ± 2%        573ms ± 3%    ~     (p=0.303 n=50+49)
Tar               240ms ± 3%        240ms ± 2%    ~     (p=0.939 n=46+44)
XML               302ms ± 2%        302ms ± 2%    ~     (p=0.399 n=47+47)
[Geo mean]        540ms             541ms       +0.07%

name        old alloc/op      new alloc/op      delta
Template         36.8MB ± 0%       36.7MB ± 0%  -0.42%  (p=0.008 n=5+5)
Unicode          28.1MB ± 0%       28.1MB ± 0%    ~     (p=0.151 n=5+5)
GoTypes           124MB ± 0%        124MB ± 0%  -0.26%  (p=0.008 n=5+5)
Compiler          571MB ± 0%        566MB ± 0%  -0.84%  (p=0.008 n=5+5)
SSA              1.86GB ± 0%       1.85GB ± 0%  -0.58%  (p=0.008 n=5+5)
Flate            22.8MB ± 0%       22.8MB ± 0%  -0.17%  (p=0.008 n=5+5)
GoParser         27.3MB ± 0%       27.3MB ± 0%  -0.20%  (p=0.008 n=5+5)
Reflect          79.5MB ± 0%       79.3MB ± 0%  -0.20%  (p=0.008 n=5+5)
Tar              34.7MB ± 0%       34.6MB ± 0%  -0.42%  (p=0.008 n=5+5)
XML              45.4MB ± 0%       45.3MB ± 0%  -0.29%  (p=0.008 n=5+5)
[Geo mean]       80.0MB            79.7MB       -0.34%

name        old allocs/op     new allocs/op     delta
Template           378k ± 0%         377k ± 0%  -0.22%  (p=0.008 n=5+5)
Unicode            339k ± 0%         339k ± 0%    ~     (p=0.643 n=5+5)
GoTypes           1.36M ± 0%        1.36M ± 0%  -0.10%  (p=0.008 n=5+5)
Compiler          5.51M ± 0%        5.50M ± 0%  -0.13%  (p=0.008 n=5+5)
SSA               17.5M ± 0%        17.5M ± 0%  -0.14%  (p=0.008 n=5+5)
Flate              234k ± 0%         234k ± 0%  -0.04%  (p=0.008 n=5+5)
GoParser           299k ± 0%         299k ± 0%  -0.05%  (p=0.008 n=5+5)
Reflect            978k ± 0%         979k ± 0%  +0.02%  (p=0.016 n=5+5)
Tar                351k ± 0%         351k ± 0%  -0.04%  (p=0.008 n=5+5)
XML                435k ± 0%         435k ± 0%  -0.11%  (p=0.008 n=5+5)
[Geo mean]         840k              840k       -0.08%

file      before    after     Δ       %
go        14794788  14770212  -24576  -0.166%
addr2line 4203688   4199592   -4096   -0.097%
api       5954056   5941768   -12288  -0.206%
asm       4862704   4846320   -16384  -0.337%
cgo       4778920   4770728   -8192   -0.171%
compile   24001568  23923792  -77776  -0.324%
cover     5198440   5190248   -8192   -0.158%
dist      3595248   3587056   -8192   -0.228%
doc       4618504   4610312   -8192   -0.177%
fix       3337416   3333320   -4096   -0.123%
link      6120408   6116312   -4096   -0.067%
nm        4149064   4140872   -8192   -0.197%
objdump   4555608   4547416   -8192   -0.180%
pprof     14616324  14595844  -20480  -0.140%
test2json 2766328   2762232   -4096   -0.148%
trace     11638844  11622460  -16384  -0.141%
vet       8274936   8258552   -16384  -0.198%
total     132520780 132270972 -249808 -0.189%

Change-Id: Ifcd235a2a6e5f13ed5c93e62523e2ef61321fccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/178197
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 22:15:13 +00:00
Bryan C. Mills
0a778cf57d cmd/go/internal/get: remove '--' separator from 'git ls-remote' command
'git ls-remote' started recognizing the '--' separator at some point
after 2.7.4, but git defaults to version 2.7.4 on Ubuntu 16.04 LTS,
which remains supported by Ubuntu until April 2021.

We added '--' tokens to most VCS commands as a defensive measure in
CL 181237, but it isn't strictly necessary here because the 'scheme'
argument to our template is chosen from a predefined list: we can
safely drop it to retain compatibility.

Fixes #33836
Updates #26746

Change-Id: Ibb53366b95f8029b587e0b7646a439330d759ac7
Reviewed-on: https://go-review.googlesource.com/c/go/+/191978
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2019-08-27 21:10:24 +00:00
Josh Bleecher Snyder
260e3d0818 cmd/compile: run deadcode before lowered CSE
CSE can make dead values live again.
Running deadcode first avoids that;
it also makes CSE more efficient.

file    before    after     Δ       %       
api     5970616   5966520   -4096   -0.069% 
asm     4867088   4846608   -20480  -0.421% 
compile 23988320  23935072  -53248  -0.222% 
link    6084376   6080280   -4096   -0.067% 
nm      4165736   4161640   -4096   -0.098% 
objdump 4572216   4568120   -4096   -0.090% 
pprof   14452996  14457092  +4096   +0.028% 
trace   11467292  11471388  +4096   +0.036% 
total   132181100 132099180 -81920  -0.062% 

Compiler performance impact is negligible:

name        old alloc/op      new alloc/op      delta
Template         38.8MB ± 0%       38.8MB ± 0%  -0.04%  (p=0.008 n=5+5)
Unicode          28.2MB ± 0%       28.2MB ± 0%    ~     (p=1.000 n=5+5)
GoTypes           131MB ± 0%        131MB ± 0%  -0.14%  (p=0.008 n=5+5)
Compiler          606MB ± 0%        606MB ± 0%  -0.05%  (p=0.008 n=5+5)
SSA              2.14GB ± 0%       2.13GB ± 0%  -0.26%  (p=0.008 n=5+5)
Flate            24.0MB ± 0%       24.0MB ± 0%  -0.18%  (p=0.008 n=5+5)
GoParser         28.8MB ± 0%       28.8MB ± 0%  -0.15%  (p=0.008 n=5+5)
Reflect          83.8MB ± 0%       83.7MB ± 0%  -0.11%  (p=0.008 n=5+5)
Tar              36.4MB ± 0%       36.4MB ± 0%  -0.09%  (p=0.008 n=5+5)
XML              47.9MB ± 0%       47.8MB ± 0%  -0.15%  (p=0.008 n=5+5)
[Geo mean]       84.6MB            84.5MB       -0.12%

name        old allocs/op     new allocs/op     delta
Template           379k ± 0%         380k ± 0%  +0.15%  (p=0.008 n=5+5)
Unicode            340k ± 0%         340k ± 0%    ~     (p=0.738 n=5+5)
GoTypes           1.36M ± 0%        1.36M ± 0%  +0.05%  (p=0.008 n=5+5)
Compiler          5.49M ± 0%        5.49M ± 0%  +0.12%  (p=0.008 n=5+5)
SSA               17.5M ± 0%        17.5M ± 0%  -0.18%  (p=0.008 n=5+5)
Flate              235k ± 0%         235k ± 0%    ~     (p=0.079 n=5+5)
GoParser           302k ± 0%         302k ± 0%    ~     (p=0.310 n=5+5)
Reflect            976k ± 0%         977k ± 0%  +0.08%  (p=0.008 n=5+5)
Tar                352k ± 0%         352k ± 0%  +0.12%  (p=0.008 n=5+5)
XML                436k ± 0%         436k ± 0%  -0.05%  (p=0.008 n=5+5)
[Geo mean]         842k              842k       +0.03%


Change-Id: I53e8faed1859885ca5c4a5d45067a50984f3eff1
Reviewed-on: https://go-review.googlesource.com/c/go/+/175879
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 21:04:53 +00:00
Stefan Baebler
cc6feab396 net/url: fail TestParseErrors test when getting an unwanted error
The TestParseErrors test function was not strict with unwanted errors
received from url.Parse(). It was not failing in such cases, now it does

Fixes #33646
Updates #29098

Change-Id: I069521093e2bff8b1fcd41ffd3f9799f3108bc61
GitHub-Last-Rev: e6844c57f9
GitHub-Pull-Request: golang/go#33876
Reviewed-on: https://go-review.googlesource.com/c/go/+/191966
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
2019-08-27 21:02:43 +00:00
Anderson Queiroz
2b59894425 net/http: enhance documentation for Server.Addr
Fixes golang/go#31249

Change-Id: I3280f8ab170ed31d4efb71106533e016d430d44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/191557
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 20:52:49 +00:00
Filippo Valsorda
2ebc3d8157 crypto/tls: make SSLv3 again disabled by default
It was mistakenly re-enabled in CL 146217.

Fixes #33837

Change-Id: I8c0e1787114c6232df5888e51e355906622295bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/191877
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2019-08-27 20:43:47 +00:00
Bryan C. Mills
8f5353fd1c cmd/go/internal/modload: fix swapped paths in error message
Updates #33879

Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/191997
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
2019-08-27 20:36:50 +00:00
Matthew Dempsky
c302785df9 cmd/compile: fix "previous" position info for duplicate switch cases
Because the Node AST represents references to declared objects (e.g.,
variables, packages, types, constants) by directly pointing to the
referred object, we don't have use-position info for these objects.

For switch statements with duplicate cases, we report back where the
first duplicate value appeared. However, due to the AST
representation, if the value was a declared constant, we mistakenly
reported the constant declaration position as the previous case
position.

This CL reports back against the 'case' keyword's position instead, if
there's no more precise information available to us.

It also refactors code to emit the same "previous at" error message
for duplicate values in map literals.

Thanks to Emmanuel Odeke for the test case.

Fixes #33460.

Change-Id: Iec69542ccd4aad594dde8df02d1b880a422c5622
Reviewed-on: https://go-review.googlesource.com/c/go/+/188901
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-27 19:53:05 +00:00
Matthew Dempsky
c1df5187d0 runtime: simplify some pointer conversions
Use efaceOf to safely convert from *interface{} to *_eface, and to
make it clearer what the pointer arithmetic is computing.

Incidentally, remove a spurious unsafe.Pointer->*uint8->unsafe.Pointer
round trip conversion in newproc.

No behavior change.

Change-Id: I2ad9d791d35d8bd008ef43b03dad1589713c5fd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/190457
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 19:51:43 +00:00
Bryan C. Mills
94bf9a8d4a net/http: fix wantConnQueue memory leaks in Transport
I'm trying to keep the code changes minimal for backporting to Go 1.13,
so it is still possible for a handful of entries to leak,
but the leaks are now O(1) instead of O(N) in the steady state.

Longer-term, I think it would be a good idea to coalesce idleMu with
connsPerHostMu and clear entries out of both queues as soon as their
goroutines are done waiting.

Fixes #33849
Fixes #33850

Change-Id: Ia66bc64671eb1014369f2d3a01debfc023b44281
Reviewed-on: https://go-review.googlesource.com/c/go/+/191964
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 18:23:13 +00:00
LE Manh Cuong
c5f142fa9f cmd/compile: optimize bitset tests
The assembly output for x & c == c, where c is power of 2:

	MOVQ	"".set+8(SP), AX
	ANDQ	$8, AX
	CMPQ	AX, $8
	SETEQ	"".~r2+24(SP)

With optimization using bitset:

	MOVQ	"".set+8(SP), AX
	BTL	$3, AX
	SETCS	"".~r2+24(SP)

output less than 1 instruction.

However, there is no speed improvement:

name         old time/op  new time/op  delta
AllBitSet-8  0.35ns ± 0%  0.35ns ± 0%   ~     (all equal)

Fixes #31904

Change-Id: I5dca4e410bf45716ed2145e3473979ec997e35d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/175957
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 18:01:16 +00:00
Daniel Martí
ae68a91272 encoding/json: remove unnecessary isValidNumber call
The decoder called this function to check numbers being decoded into a
json.Number. However, these can't be quoted as strings, so the tokenizer
has already verified they are valid JSON numbers.

Verified this by adding a test with such an input. As expected, it
produces a syntax error, not the fmt.Errorf - that line could never
execute.

Since the only remaining non-test caller of isvalidnumber is in
encode.go, move the function there.

This change should slightly reduce the amount of work when decoding into
json.Number, though that isn't very common nor part of any current
benchmarks.

Change-Id: I67a1723deb3d18d5b542d6dd35f3ae56a43f23eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/184817
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-27 17:53:55 +00:00
Dong-hee Na
b9bf2f5d2b html/template: micro optimization for isJSType
There is an unnecessary lower operation in isJSType.
Simple logic fix can improve tiny performance.

name        old time/op    new time/op    delta
isJSType-8     152ns ± 0%      58ns ± 7%   -61.82%  (p=0.001 n=6+8)

name        old alloc/op   new alloc/op   delta
isJSType-8     32.0B ± 0%      0.0B       -100.00%  (p=0.000 n=8+8)

name        old allocs/op  new allocs/op  delta
isJSType-8      1.00 ± 0%      0.00       -100.00%  (p=0.000 n=8+8)

Change-Id: I281aadf1677d4377920c9649af206381189a27e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/177118
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2019-08-27 17:41:33 +00:00
Daniel Martí
72e71b90f3 Revert "net/url: fail TestParseErrors test when getting an unwanted error"
This reverts https://golang.org/cl/185080.

Reason for revert: some new changes are erroring again, so this broke the builders.

Change-Id: I28da16da98b90cefbb47173d31bbbb56e43062d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/191781
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2019-08-27 17:25:52 +00:00
LE Manh Cuong
1a432f27d5 cmd/compile: eliminate usage of global Fatalf in ssa.go
state and ssafn both have their own Fatalf, so use them instead of
global Fatalf.

Updates #19683

Change-Id: Ie02a961d4285ab0a3f3b8d889a5b498d926ed567
Reviewed-on: https://go-review.googlesource.com/c/go/+/188539
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 17:05:15 +00:00
Daniel Martí
79dee788ec cmd/compile: teach rulegen to remove unused decls
First, add cpu and memory profiling flags, as these are useful to see
where rulegen is spending its time. It now takes many seconds to run on
a recent laptop, so we have to keep an eye on what it's doing.

Second, stop writing '_ = var' lines to keep imports and variables used
at all times. Now that rulegen removes all such unused names, they're
unnecessary.

To perform the removal, lean on go/types to first detect what names are
unused. We can configure it to give us all the type-checking errors in a
file, so we can collect all "declared but not used" errors in a single
pass.

We then use astutil.Apply to remove the relevant nodes based on the line
information from each unused error. This allows us to apply the changes
without having to do extra parser+printer roundtrips to plaintext, which
are far too expensive.

We need to do multiple such passes, as removing an unused variable
declaration might then make another declaration unused. Two passes are
enough to clean every file at the moment, so add a limit of three passes
for now to avoid eating cpu uncontrollably by accident.

The resulting performance of the changes above is a ~30% loss across the
table, since go/types is fairly expensive. The numbers were obtained
with 'benchcmd Rulegen go run *.go', which involves compiling rulegen
itself, but that seems reflective of how the program is used.

	name     old time/op         new time/op         delta
	Rulegen          5.61s ± 0%          7.36s ± 0%  +31.17%  (p=0.016 n=5+4)

	name     old user-time/op    new user-time/op    delta
	Rulegen          7.20s ± 1%          9.92s ± 1%  +37.76%  (p=0.016 n=5+4)

	name     old sys-time/op     new sys-time/op     delta
	Rulegen          135ms ±19%          169ms ±17%  +25.66%  (p=0.032 n=5+5)

	name     old peak-RSS-bytes  new peak-RSS-bytes  delta
	Rulegen         71.0MB ± 2%         85.6MB ± 2%  +20.56%  (p=0.008 n=5+5)

We can live with a bit more resource usage, but the time/op getting
close to 10s isn't good. To win that back, introduce concurrency in
main.go. This further increases resource usage a bit, but the real time
on this quad-core laptop is greatly reduced. The final benchstat is as
follows:

	name     old time/op         new time/op         delta
	Rulegen          5.61s ± 0%          3.97s ± 1%   -29.26%  (p=0.008 n=5+5)

	name     old user-time/op    new user-time/op    delta
	Rulegen          7.20s ± 1%         13.91s ± 1%   +93.09%  (p=0.008 n=5+5)

	name     old sys-time/op     new sys-time/op     delta
	Rulegen          135ms ±19%          269ms ± 9%   +99.17%  (p=0.008 n=5+5)

	name     old peak-RSS-bytes  new peak-RSS-bytes  delta
	Rulegen         71.0MB ± 2%        226.3MB ± 1%  +218.72%  (p=0.008 n=5+5)

It might be possible to reduce the cpu or memory usage in the future,
such as configuring go/types to do less work, or taking shortcuts to
avoid having to run it many times. For now, ~2x cpu and ~4x memory usage
seems like a fair trade for a faster and better rulegen.

Finally, we can remove the old code that tried to remove some unused
variables in a hacky and unmaintainable way.

Change-Id: Iff9e83e3f253babf5a1bd48cc993033b8550cee6
Reviewed-on: https://go-review.googlesource.com/c/go/+/189798
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 17:04:18 +00:00
Andrew Gerrand
483d6d9925 archive/zip: remove unused special case
This removes a special case that was added to fix issue #10956, but that
was never actually effective. The code in the test case still fails to
read, so perhaps the zip64 support added in CL 6463050 inadvertently
caught this particular case.

It's possible that the original theorized bug still exists, but I'm not
convinced it was ever fixed.

Update #28700

Change-Id: I4854de616364510f64a6def30b308686563f8dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/179757
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 17:00:43 +00:00
tnclong
4a4f752c38 text/template: avoid allocating a new common in copy
Template.New calls t.init, which allocates several items that
are immediately rewritten by copy, so avoid the call to New

Change-Id: I16c7cb001bbcd14cf547c1a2db2734a2f8214e7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182757
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
2019-08-27 16:56:26 +00:00
Stefan Baebler
32b9e568d8 net/url: fail TestParseErrors test when getting an unwanted error
The TestParseErrors test function was not strict with unwanted errors
received from url.Parse(). It was not failing in such cases, now it does.

Change-Id: I18a26a68c1136f5c762989a76e04b47e33dd35f1
GitHub-Last-Rev: c33f9842f7
GitHub-Pull-Request: golang/go#32954
Reviewed-on: https://go-review.googlesource.com/c/go/+/185080
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-27 16:55:43 +00:00
Alex Brainman
b963149d4e net: do not call Windows TransmitFile for large files
TransmitFile does not allow for number of bytes that can be
transmitted to be larger than 2147483646. See

https://docs.microsoft.com/en-us/windows/win32/api/mswsock/nf-mswsock-transmitfile

for details. So adjust sendFile accordingly.

No test added, because this would require creating large file
(more than 2GB file).

Fixes #33193.

Change-Id: I82e0cb104d112264e4ea363bb20b6d02ac30b38e
Reviewed-on: https://go-review.googlesource.com/c/go/+/187037
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2019-08-27 16:54:49 +00:00
Dong-hee Na
997086b7e6 text/template: replace bytes.Buffer with strings.Builder
After Go.1.10+ strings.Builder is known as more efficient in
concatenating and building strings than bytes.Buffer.

In this CL,
there is a minor logic fix for getting advantage of strings.builder.

name               old time/op    new time/op    delta
DefinedTemplate-8     543ns ± 3%     512ns ± 2%   -5.73%  (p=0.000 n=8+8)

name               old alloc/op   new alloc/op   delta
DefinedTemplate-8      192B ± 0%      160B ± 0%  -16.67%  (p=0.000 n=8+8)

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

Change-Id: Icda0054d146e6c5e32ed8a4d13221bb6850d31b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/175261
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-08-27 16:54:06 +00:00
Jonathan Amsterdam
fc4663d56f errors: document Is and As methods
Add brief descriptions of why one might implement
an Is or As method.

Fixes #33364.

Change-Id: I81a091bf564c654ddb9ef3997e780451a01efb7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/191338
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-27 16:51:42 +00:00
Daniel Martí
95c3c43072 encoding/json: fix the broken "overwriting of data" tests
Because TestUnmarshal actually allocates a new value to decode into
using ptr's pointer type, any existing data is thrown away. This was
harmless in alomst all of the test cases, minus the "overwriting of
data" ones added in 2015 in CL 12209.

I spotted that nothing covered decoding a JSON array with few elements
into a slice which already had many elements. I initially assumed that
the code was buggy or that some code could be removed, when in fact
there simply wasn't any code covering the edge case.

Move those two tests to TestPrefilled, which already served a very
similar purpose. Remove the map case, as TestPrefilled already has
plenty of prefilled map cases. Moreover, we no longer reset an entire
map when decoding, as per the godoc:

	To unmarshal a JSON object into a map, Unmarshal first
	establishes a map to use. If the map is nil, Unmarshal allocates
	a new map. Otherwise Unmarshal reuses the existing map, keeping
	existing entries.

Finally, to ensure that ptr is used correctly in the future, make
TestUnmarshal error if it's anything other than a pointer to a zero
value. That is, the only correct use should be new(type). Don't rename
the ptr field, as that would be extremely noisy and cause unwanted merge
conflicts.

Change-Id: I41e3ecfeae42d877ac5443a6bd622ac3d6c8120c
Reviewed-on: https://go-review.googlesource.com/c/go/+/185738
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2019-08-27 16:50:56 +00:00
Daniel Martí
1a53915c6b cmd/compile: initial rulegen rewrite
rulegen.go produces plaintext Go code directly, which was fine for a
while. However, that's started being a bottleneck for making code
generation more complex, as we can only generate code directly one line
at a time.

Some workarounds were used, like multiple layers of buffers to generate
chunks of code, to then use strings.Contains to see whether variables
need to be defined or not. However, that's error-prone, verbose, and
difficult to work with.

A better approach is to generate an intermediate syntax tree in memory,
which we can inspect and modify easily. For example, we could run a
number of "passes" on the syntax tree before writing to disk, such as
removing unused variables, simplifying logic, or moving declarations
closer to their uses.

This is the first step in that direction, without changing any of the
generated code. We didn't use go/ast directly, as it's too complex for
our needs. In particular, we only need a few kinds of simple statements,
but we do want to support arbitrary expressions. As such, define a
simple set of statement structs, and add thin layers for printer.Fprint
and ast.Inspect.

A nice side effect of this change, besides removing some buffers and
string handling, is that we can now avoid passing so many parameters
around. And, while we add over a hundred lines of code, the tricky
pieces of code are now a bit simpler to follow.

While at it, apply some cleanups, such as replacing isVariable with
token.IsIdentifier, and consistently using log.Fatalf.

Follow-up CLs will start improving the generated code, also simplifying
the rulegen code itself. I've added some TODOs for the low-hanging fruit
that I intend to work on right after.

Updates #30810.

Change-Id: Ic371c192b29c85dfc4a001be7fbcbeec85facc9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/177539
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 16:50:45 +00:00
Javier Revillas
cd33d271b4 net/http: fix a typo in comments
HTTP is an initialism, not an acronym, where you pronounce each letter as a
word. It's "an H", not "a H".

Running `find src/net/http -type f | xargs grep -n 'an HTTP' | wc -l` shows
that the "an HTTP" form is used 67 times across the `net/http` package.
Furthermore, `find src/net/http -type f | xargs grep -n 'a HTTP' | wc -l`
yields only 4 results.

Change-Id: I219c292a9e2c9bf7a009dbfe82ea8b15874685e9
GitHub-Last-Rev: 6ebd095023
GitHub-Pull-Request: golang/go#33810
Reviewed-on: https://go-review.googlesource.com/c/go/+/191700
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-08-27 16:50:35 +00:00
LE Manh Cuong
324cf21f78 cmd/compile: remove adjustctx from inline test
After golang.org/cl/33895, function adjustctx can not be inlined,
cost 82 exceeds budget 80

Change-Id: Ie559ed80ea2c251add940a99f11b2983f6cbddbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/187977
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2019-08-27 16:47:06 +00:00
zdjones
69ff0ba798 cmd/compile: handle sign/zero extensions in prove, via update method
Array accesses with index types smaller than the machine word size may
involve a sign or zero extension of the index value before bounds
checking. Currently, this defeats prove because the facts about the
original index value don't flow through the sign/zero extension.

This CL fixes this by looking back through value-preserving sign/zero
extensions when adding facts via Update and, where appropriate, applying
the same facts using the pre-extension value. This fix is enhanced by
also looking back through value-preserving extensions within
ft.isNonNegative to infer whether the extended value is known to be
non-negative. Without this additional isNonNegative enhancement, this
logic is rendered significantly less effective by the limitation
discussed in the next paragraph.

In Update, the application of facts to pre-extension values is limited
to cases where the domain of the new fact is consistent with the type of
the pre-extension value. There may be cases where this cross-domain
passing of facts is valid, but distinguishing them from the invalid
cases is difficult for me to reason about and to implement.
Assessing which cases to allow requires details about the context and
inferences behind the fact being applied which are not available
within Update. Additional difficulty arises from the fact that the SSA
does not curently differentiate extensions added by the compiler for
indexing operations, extensions added by the compiler for implicit
conversions, or explicit extensions from the source.

Examples of some cases that would need to be filtered correctly for
cross-domain facts:

(1) A uint8 is zero-extended to int for indexing (a value-preserving
zeroExt). When, if ever, can signed domain facts learned about the int be
applied to the uint8?

(2) An int8 is sign-extended to int16 (value-preserving) for an equality
comparison. Equality comparison facts are currently always learned in both
the signed and unsigned domains. When, if ever, can the unsigned facts
learned about the int16, from the int16 != int16 comparison, be applied
to the original int8?

This is an alternative to CL 122695 and CL 174309. Compared to CL 122695,
this CL differs in that the facts added about the pre-extension value will
pass through the Update method, where additional inferences are processed
(e.g. fence-post implications, see #29964). CL 174309 is limited to bounds
checks, so is narrower in application, and makes the code harder to read.

Fixes #26292.
Fixes #29964.
Fixes #15074

Removes 238 bounds checks from std/cmd.

Change-Id: I1f87c32ee672bfb8be397b27eab7a4c2f304893f
Reviewed-on: https://go-review.googlesource.com/c/go/+/174704
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
2019-08-27 16:46:34 +00:00