No extra buffering is needed to save the encoding
since the left padding can be computed and written out
before the encoding is generated.
Add extra tests to both string and byte slice formatting.
name old time/op new time/op delta
SprintfHexString-2 410ns ± 3% 194ns ± 3% -52.60% (p=0.000 n=20+19)
SprintfHexBytes-2 431ns ± 3% 202ns ± 2% -53.13% (p=0.000 n=18+20)
Change-Id: Ibca4316427c89f834e4faee61614493c7eedb42b
Reviewed-on: https://go-review.googlesource.com/20097
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The ODOTPTRs introduced in CL #19814 don't have field names,
just offsets. The fieldtrack experiment crashes when
examining them. Instead, just ignore them. We'll never track
these fields anyway.
It would be nice to have the runtime type struct build in the
compiler (like we do sudog, for example) so we could use its
fieldnames. Doesn't seem worth it just for this CL.
Change-Id: I5e75024f5a8333eb7439543b3f466ea40213a1b9
Reviewed-on: https://go-review.googlesource.com/20157
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new Minalign field sets the minimum alignment for all symbols.
This is required for the upcoming s390x port which requires symbols
be 2-byte aligned for efficient relative addressing.
All preexisting architectures have Minalign set to 1 which means
that this commit should have no effect.
I tested values of 2, 4 and 8 on linux amd64 and the tests appear to
pass. Increasing Minalign to 16 appears to break the runtime. I
think this is due to assumptions made about the layout of module
data.
toolstash -cmp on linux amd64 shows no changes due to this commit.
Resolves#14604
Change-Id: I0fe042d52c4e4732eba5fabcd0c31102a2408764
Reviewed-on: https://go-review.googlesource.com/20149
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change consolidates functions and methods related to TCPAddr,
TCPConn and TCPListener for maintenance purpose, especially for
documentation. Also refactors Dial error code paths.
The followup changes will update comments and examples.
Updates #10624.
Change-Id: I3333ee218ebcd08928f9e2826cd1984d15ea153e
Reviewed-on: https://go-review.googlesource.com/20009
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Over the years as more bugs were discovered with the bzip2 library,
new Tests were appended the unit tests and the tests became gnarly.
Clean up the tests to be more consistent with modern Go style in
addition to coalescing common tests into a general version that
iterates over a list of input/output pairs. This has the advantage that
the input, output, and test code are all in the same area, rather than
being sprawled around the test file.
There is no loss of test coverage.
Change-Id: I377ed89378f0b89763d4a56ffc37b22d9c2a369e
Reviewed-on: https://go-review.googlesource.com/20133
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
/etc/services is not available on Android. The pure Go implementation
of LookupPort will never succeed on Android. Skipping the test.
Updates #14576.
Change-Id: I707ac24aea3f988656b95b1816ee5c9690106985
Reviewed-on: https://go-review.googlesource.com/20154
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It appears to be a trivial dreg. Unreferenced. Gone.
Change-Id: I4a5ceed48e84254bc8a07fdb04487a18a0edf965
Reviewed-on: https://go-review.googlesource.com/20122
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Arch backends already provide us Widthint and Widthptr, which is ample
information to figure out how to define the universal "int", "uint",
and "uintptr" types. No need for providing a generic typedef
mechanism beyond that.
Change-Id: I35c0c17a67c80605a9208b93d77d6960b2cbb17d
Reviewed-on: https://go-review.googlesource.com/20153
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
No performance improvement, but possibly more readable.
Linking juju:
tip: real 0m5.470s user 0m6.131s
this: real 0m5.392s user 0m6.087s
Change-Id: I578e94fbe6c11b19d79034c33b3db31d9689d439
Reviewed-on: https://go-review.googlesource.com/20108
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
All callers already had strings. No need to generate byte slice copies
to work on bytes.
Performance not measured, but probably helps at least a bit.
Change-Id: Iec3230b69724fac68caae7aad46f2ce1504e82e5
Reviewed-on: https://go-review.googlesource.com/20136
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Latest version of gcc (tdm-1) 5.1.0 refuses to compile our code
on windows/386 (see issue for details). Rewrite the code.
Fixes#14328
Change-Id: I70f4f063282bd2958cd2175f3974369dd49dd8dc
Reviewed-on: https://go-review.googlesource.com/20008
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Looks a tiny bit faster, which is a surprise. Probably noise.
Motivation is making the LSym structure a little easier to understand.
Linking juju, best of 10:
before: real 0m4.811s user 0m5.582s
after: real 0m4.611s user 0m5.267s
Change-Id: Idbedaf4a6e6e199036a1bbb6760e98c94ed2c282
Reviewed-on: https://go-review.googlesource.com/20142
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Function bodies are not yet hooked up because the node structure is not
100% correct. This commit establishes that we can correctly write bodies
out and read them in again.
- export and import all exported inlined function bodies:
(export GO_GCFLAGS="-newexport"; sh all.bash) working
- inlined functions are not yet hooked up (just dropped on the floor)
- improved tracing output and error messages
- make mkbuiltin.go work for both textual and binary export data
so we can run tests with the new format
Change-Id: I70dc4de419df1b604389c3747041d6dba8730b0b
Reviewed-on: https://go-review.googlesource.com/16284
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Also stop creating a map for each symbol, as it does not seem to help.
Linking juju:
tip: real 0m5.470s user 0m6.131s
this: real 0m4.811s user 0m5.582s
Change-Id: Ib3d931c996396a00942581770ff32df1eb8d6615
Reviewed-on: https://go-review.googlesource.com/20140
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
uint8(s.b & 0xff) ought to produce same code as uint8(s.b)
but it did not. RLH found this one looking for moles to
whack in the GC code.
Change-Id: I883d68ec7a5746d652712be84a274a11256b3b33
Reviewed-on: https://go-review.googlesource.com/20141
Reviewed-by: Keith Randall <khr@golang.org>
Count only the runes up to the requested precision
to decide where to truncate a string.
Change the loop within truncate to need fewer jumps.
name old time/op new time/op delta
SprintfTruncateString-2 188ns ± 3% 155ns ± 3% -17.43% (p=0.000 n=20+20)
Change-Id: I17ca9fc0bb8bf7648599df48e4785251bbc31e99
Reviewed-on: https://go-review.googlesource.com/20098
Reviewed-by: Rob Pike <r@golang.org>
- removed lots of unnecessary int(x) casts
- removed parserline() - was inconsistently used anyway
- minor simplifications in dcl.go
Change-Id: Ibf7de679eea528a31c9692ef1c76a1d9b3239211
Reviewed-on: https://go-review.googlesource.com/20131
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This promotes a connection hang during TLS handshake to a proper error.
This doesn't fully address #14539 because the error reported in that
case is a write-on-socket-not-connected error, which implies that an
earlier error during connection setup is not being checked, but it is
an improvement over the current behaviour.
Updates #14539.
Change-Id: I0571a752d32d5303db48149ab448226868b19495
Reviewed-on: https://go-review.googlesource.com/19990
Reviewed-by: Adam Langley <agl@golang.org>
It looks like the compiler still uses the Cfunc flag for functions
marked as //go:systemstack, but if I'm reading this right, that
doesn't apply here and the linker no longer needs Cfunc.
Change-Id: I63b9192c2f52f41401263c29dc8dfd8be8a901a1
Reviewed-on: https://go-review.googlesource.com/20105
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Unlike RFC 1951 (DEFLATE), bzip2 does not use zero-length Huffman codes
to indicate that the symbol is missing. Instead, bzip2 uses a sparse
bitmap to indicate which symbols are present. Thus, it is undefined what
happens when a length of zero is used. Thus, fix the parsing logic so that
the length cannot ever go below 1-bit similar to how the C logic does things.
To confirm that the C bzip2 utility chokes on this data:
$ echo "425a6836314159265359b1f7404b000000400040002000217d184682ee48
a70a12163ee80960" | xxd -r -p | bzip2 -d
bzip2: Data integrity error when decompressing
For reference see:
bzip2-1.0.6/decompress.c:320
Change-Id: Ic1568f8e7f80cdea51d887b4d712cc239c2fe85e
Reviewed-on: https://go-review.googlesource.com/20119
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This per-symbol table was written with the strategy:
1. record offset and write fake header
2. write body
3. seek back to fake header
4. write real header
This CL collects the per-symbol body into a []byte, then writes the
real header followed by the body to the output file. This saves two
seeks per-symbol and overwriting the fake header.
Small performance improvement (3.5%) in best-of-ten links of godoc:
tip: real 0m1.132s user 0m1.256s
this: real 0m1.090s user 0m1.210s
I'm not sure if the performance measured here alone justifies it,
but I think this is an easier to read style of code.
Change-Id: I1663901eb7c2ee330591b8b6550cdff0402ed5dc
Reviewed-on: https://go-review.googlesource.com/20074
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Used by DWARF writer changes in a followup CL.
Change-Id: I6ec40dcfeaba909d9b8f6cf2603bc5b85c1fa873
Reviewed-on: https://go-review.googlesource.com/20073
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Do some easy TODOs.
Move a bunch of other TODOs into bugs.
Change-Id: Iaba9dad6221a2af11b3cbcc512875f4a85842873
Reviewed-on: https://go-review.googlesource.com/20114
Run-TryBot: Todd Neal <todd@tneal.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>
This commit modifies the style of a error message in case of -shadow.
Previously such a message would look like:
foo.go:42: declaration of err shadows declaration at shadow.go:13:
Changes of the commit include highlighting the variable name and
removing the ": "(space intended) at the end of the line:
foo.go:42: declaration of "err" shadows declaration at shadow.go:13
Fixes#14585.
Change-Id: Ia6a6bf396668dcba9a24f025a08d8826db31f434
Reviewed-on: https://go-review.googlesource.com/20093
Reviewed-by: Rob Pike <r@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The size calculation has been wrong since this code was first committed
in https://golang.org/cl/3120. The effect was that the compiler always
allocated a temporary buffer on the stack for a non-escaping string
concatenation. This turns out to make no practical difference, as the
compiler always allocates a buffer of the same size (32 bytes) and the
runtime only uses the temporary buffer if the concatenated strings
fit (check is in rawstringtmp in runtime/string.go).
The effect of this change is to avoid generating a temporary buffer on
the stack that will not be used.
Change-Id: Id632bfe3d6c113c9934c018a2dd4bcbf1784a63d
Reviewed-on: https://go-review.googlesource.com/20112
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This check seems to apply to all code instrumentation, not just -race.
Fixes#14589.
Change-Id: I16ae07749ede7c1e6ed06f472711638d195034ac
Reviewed-on: https://go-review.googlesource.com/20113
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also: Use same ordering of tokens in the various tables/maps.
Change-Id: Ief84c6ca3da36213ace6b2c10b513e2ca16318ab
Reviewed-on: https://go-review.googlesource.com/20110
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
SSA is a real compiler now, don't trigger on function names.
Change-Id: Iaf6dd78248c1b6ca2630275bd59f7ea7b7576497
Reviewed-on: https://go-review.googlesource.com/20088
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Static branch predictions (which guide block ordering) are
adjusted based on:
loop/not-loop (favor looping)
abnormal-exit/not (avoid panic)
call/not-call (avoid call)
ret/default (treat returns as rare)
This appears to make no difference in performance of real
code, meaning the compiler itself. The earlier version of
this has been stripped down to help make the cost of this
only-aesthetic-on-Intel phase be as cheap as possible (we
probably want information about inner loops for improving
register allocation, but because register allocation follows
close behind this pass, conceivably the information could be
reused -- so we might do this anyway just to normalize
output).
For a ./make.bash that takes 200 user seconds, about .75
second is reported in likelyadjust (summing nanoseconds
reported with -d=ssa/likelyadjust/time ).
Upstream predictions are respected.
Includes test, limited to build on amd64 only.
Did several iterations on the debugging output to allow
some rough checks on behavior.
Debug=1 logging notes agree/disagree with earlier passes,
allowing analysis like the following:
Run on make.bash:
GO_GCFLAGS=-d=ssa/likelyadjust/debug \
./make.bash >& lkly5.log
grep 'ranch prediction' lkly5.log | wc -l
78242 // 78k predictions
grep 'ranch predi' lkly5.log | egrep -v 'agrees with' | wc -l
29633 // 29k NEW predictions
grep 'disagrees' lkly5.log | wc -l
444 // contradicted 444 times
grep '< exit' lkly5.log | wc -l
10212 // 10k exit predictions
grep '< exit' lkly5.log | egrep 'disagrees' | wc -l
5 // 5 contradicted by previous prediction
grep '< exit' lkly5.log | egrep -v 'agrees' | wc -l
702 // 702-5 redundant with previous prediction
grep '< call' lkly5.log | egrep -v 'agrees' | wc -l
16699 // 16k new call predictions
grep 'stay in loop' lkly5.log | egrep -v 'agrees' | wc -l
3951 // 4k new "remain in loop" predictions
Fixes#11451.
Change-Id: Iafb0504f7030d304ef4b6dc1aba9a5789151a593
Reviewed-on: https://go-review.googlesource.com/19995
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
