The (pc, line) deltas in the line number information are currently encoded
either with a special opcode, or with a triplet of DW_LNS_advance_pc,
DW_LNS_advance_line, and DW_LNS_copy instructions. Instead of DW_LNS_copy,
this change always uses a special opcode, which can make DW_LNS_advance_pc or
DW_LNS_advance_line unnecessary, or make their operands take fewer bytes. It
chooses the special opcode so that the encoding of the remaining deltas is as
small as possible.
Use DW_LNS_const_add_pc or DW_LNS_fixed_advance_pc instead of DW_LNS_advance_pc
for deltas where they save a byte.
Update LINE_BASE and LINE_RANGE constants to optimal values for this strategy.
This reduces line number information by about 35% and total size by about 2%
for a typical binary.
Change-Id: Ia61d6bf19c95c1d34ba63c67ed32b376beda225f
Reviewed-on: https://go-review.googlesource.com/30577
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
- Add new BenchmarkQuoRem.
- Eliminate allocation in divLarge nat pool
- Unroll mulAddVWW body 4x
- Remove some redundant slice loads in divLarge
name old time/op new time/op delta
QuoRem-8 2.18µs ± 1% 1.93µs ± 1% -11.38% (p=0.000 n=19+18)
The starting point in the comparison here is Cherry's
pending CL to turn mulWW and divWW into intrinsics.
The optimizations in divLarge work best because all
the function calls are gone. The effect of this CL is not
as large if you don't assume Cherry's CL.
Change-Id: Ia6138907489c5b9168497912e43705634e163b35
Reviewed-on: https://go-review.googlesource.com/30613
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This, along with CL 30140, removes ~50% of stack write barriers
mentioned in issue #17330. The remaining are most due to Phi and
FwdRef, which is not resolved when building SSA. We might be
able to do it at a later stage where Phi and Copy propagations
are done, but matching an if-(store-store-call)+ sequence seems
not very pleasant.
Updates #17330.
Change-Id: Iaa36c7b1f4c4fc3dc10a27018a3b0e261094cb21
Reviewed-on: https://go-review.googlesource.com/30290
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Inputs to store[BHW] and cmpW(U) need not be correct
in more bits than are used by the instruction.
Added a pattern tailored to what appears to be cgo boilerplate.
Added a pattern (also seen in cgo boilerplate and hashing)
to replace {EQ,NE}-CMP-ANDconst with {EQ-NE}-ANDCCconst.
Added a pattern to clean up ANDconst shift distance inputs
(this was seen in hashing).
Simplify repeated and,or,xor.
Fixes#17109.
Change-Id: I68eac83e3e614d69ffe473a08953048c8b066d88
Reviewed-on: https://go-review.googlesource.com/30455
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is a followup to issue #13805. That change avoid leaks for types that
don't have any pointers for the single assignment form of a dottype expression.
This does the same for the double assignment form.
Fixes#15796
Change-Id: I27474cade0ff1f3025cb6392f47b87b33542bc0f
Reviewed-on: https://go-review.googlesource.com/24906
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Renamed TestPOSTQuery to TestParseFormQuery and added testing
for the ";" delimiter, an empty key, an empty value and an
empty key + value.
Also added TestParseFormQueryMethods to make sure forms sent in
PATCH and PUT (and no others) request are parsed correctly in
ParseForm.
Fixes#17368
Change-Id: I445aad324ffc7b38d179ea41953bffbac0cddffe
Reviewed-on: https://go-review.googlesource.com/30555
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL removes support for MOVD instructions that store the address
of a global variable. For example:
MOVD $main·a(SB), (R1)
MOVD $main·b(SB), main·c(SB)
These instructions are emulated and the new backend doesn't need them
(the stores now always go through an intermediate register).
Change-Id: I3a1bcb3f19c5096ad0426afd76d35a4d7975733b
Reviewed-on: https://go-review.googlesource.com/30720
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With this change, the code in bug #15609 compiles and runs properly:
0000000000401070 <main.jump>:
401070: ff 15 aa 7e 06 00 callq *0x67eaa(%rip) # 468f20 <main.pointer>
401076: c3 retq
0000000000468f20 g O .rodata 0000000000000008 main.pointer
Fixes#15609
Change-Id: Iebb4d5a9f9fff335b693f4efcc97882fe04eefd7
Reviewed-on: https://go-review.googlesource.com/22950
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
With help of a new interactive commit classifier tool (tool location
TBD, likely x/build/cmd/writenotes), classify all commits from go1.7
up to 56d35d4.
We can selectively cull this list later. When in doubt, I erred on the
side of inclusion for now.
Change-Id: I458945004e1b1a148fb2f294b454a390ef4f92c2
Reviewed-on: https://go-review.googlesource.com/30696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TESTB was implemented as AND $0xff, Rx, REGTMP. Unfortunately there
is no 3-operand AND-with-immediate instruction and so it was emulated
by the assembler using two instructions.
This CL uses CMPW instead of AND and also optimizes CMPW to use
the chi instruction where possible.
Overall this CL reduces the size of the .text section of the
bin/go binary by ~2%.
Change-Id: Ic335c29fc1129378fcbb1265bfb10f5b744a0f3f
Reviewed-on: https://go-review.googlesource.com/30690
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
No need to build a bespoke dom tree here when we might
have one cached already. The allocations for the dom tree
were also more expensive than they needed to be.
Fixes#12021
Change-Id: I6a967880aee03660ad6fc293f8fc783779cae11d
Reviewed-on: https://go-review.googlesource.com/30671
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The algorithm for placing a phi nodes in small functions now
unreachable. This patch fix that.
Change-Id: I253d745b414fa12ee0719459c28e78a69c6861ae
Reviewed-on: https://go-review.googlesource.com/30106
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently these are labeled "MARK", which was accurate in the STW
collector, but these really indicate mark termination now, since
marking happens for the full duration of the concurrent GC. Re-label
them as "MARK TERMINATION" to clarify this.
Change-Id: Ie98bd961195acde49598b4fa3f9e7d90d757c0a6
Reviewed-on: https://go-review.googlesource.com/30018
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Currently, the process-wide GC state is attributed to the P that
happened to perform the allocation that exceeded the GC trigger. This
is pretty arbitrary and makes it hard to see when GC is running since
the GC spans are intermingled with a lot of other trace noise.
The current display is particularly confusing because it creates three
sub-rows in the P row that can overlap each other. Usually a P has
just two sub-rows: one showing the current G and another showing that
G's activity. However, because GC is attributed to a proc, it winds up
as a third row that neither subsumes nor is subsumed by any other row.
This in turn screws up the trace's layout and results in overlapping
events.
Fix these problems by creating a new dedicated row like the existing
"Network" and "Timer" rows and displaying process-wide GC events in
this row. Mark termination and sweep events still appear in their
respective P rows because these are meaningfully attributed.
Change-Id: Ie1a1c6cf8c446e4b043f10f3968f91ff1b546d15
Reviewed-on: https://go-review.googlesource.com/30017
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
When GC is disabled, we set gcpercent to -1. However, we still use
gcpercent to compute several values, such as next_gc and gc_trigger.
These calculations are meaningless when gcpercent is -1 and result in
meaningless values. This is okay in a sense because we also never use
these values if gcpercent is -1, but they're confusing when exposed to
the user, for example via MemStats or the execution trace. It's
particularly unfortunate in the execution trace because it attempts to
plot the underflowed value of next_gc, which scales all useful
information in the heap row into oblivion.
Fix this by making next_gc ^0 when gcpercent < 0. This has the
advantage of being true in a way: next_gc is effectively infinite when
gcpercent < 0. We can also detect this special value when updating the
execution trace and report next_gc as 0 so it doesn't blow up the
display of the heap line.
Change-Id: I4f366e4451f8892a4908da7b2b6086bdc67ca9a9
Reviewed-on: https://go-review.googlesource.com/30016
Reviewed-by: Rick Hudson <rlh@golang.org>
No point doing this check all the time.
Fixes#15621
Change-Id: I1966c061986fe98fe9ebe146d6b9738c13cef724
Reviewed-on: https://go-review.googlesource.com/30670
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL makes minor adjustment to the handling of spaces and newlines
and then documents the result.
The semantic adjustment mainly concerns the handling of a run of
spaces following a newline in the format, like in "\n ".
Previously, that run of spaces was ignored entirely, leading to paradoxes
like the format "1 \n 2" not matching itself as input.
Now, spaces following a newline in the format match zero or more
spaces following the corresponding newline in the input.
The changes to the test suite show how minor the semantic adjustments are
and how they make the behavior more regular than previously.
This CL also updates the documentation to explain the handling of
spaces more precisely, incorporating the draft from CL 17723 but
describing the newly introduced behavior.
Fixes#13565.
Change-Id: I129666e9ba42de3c28b67f75cb47488e9a4c1867
Reviewed-on: https://go-review.googlesource.com/30611
Reviewed-by: Rob Pike <r@golang.org>
There are no semantic changes here, just tests to establish
the status quo. A followup CL will make some semantic changes,
the (limited) scope of which should be clear from the number of
tests that change.
For #13565.
Change-Id: I960749cf59d4dfe39c324875bcc575096654f883
Reviewed-on: https://go-review.googlesource.com/30610
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
On 64-bit big-endian GNU/Linux machines we need to treat sigset as a
single uint64, not as a pair of uint32 values. This fix was already made
for s390x, but not for ppc64 (which is big-endian--the little endian
version is known as ppc64le). So copy os_linux_390.x to
os_linux_be64.go, and use build constraints as needed.
Fixes#17361
Change-Id: Ia0eb18221a8f5056bf17675fcfeb010407a13fb0
Reviewed-on: https://go-review.googlesource.com/30602
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This simply documents the status quo accepted by cmd/compile, gccgo,
and go/types. The new language matches the language used for indices
of index expressions for arrays and slices.
Fixes#16679.
Change-Id: I65447889fbda9d222f2a9e6c10334d1b38c555f0
Reviewed-on: https://go-review.googlesource.com/30474
Reviewed-by: Rob Pike <r@golang.org>
AddDate now retrieves location from t.Location() to ensure that
it never calls Date with a nil location.
Added test for this bug on all Time's methods
Fixes#15852
Change-Id: Id2a222af56993f741ad0b802a2c3b89e8e463926
Reviewed-on: https://go-review.googlesource.com/23561
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
It tests the behavior of the old deleted compiler.
Fixes#17362.
Change-Id: Ia2fdec734c5cbe724a9de562ed71598f67244ab3
Reviewed-on: https://go-review.googlesource.com/30593
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Using 387 mode was computing it without underflow to zero,
apparently due to an 80-bit intermediate. Avoid underflow even
with 64-bit floats.
This eliminates the TODOs in the test suite.
Fixes linux-386-387 build and fixes#11441.
Change-Id: I8abaa63bfdf040438a95625d1cb61042f0302473
Reviewed-on: https://go-review.googlesource.com/30540
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Struct fields can be suppressed in JSON serialization by "-" tags, but
that doesn't preclude generation of "-" object keys.
Document and verify the mechanism for doing so.
Change-Id: I7f60e1759cfee15cb7b2447cd35fab91c5b004e6
Reviewed-on: https://go-review.googlesource.com/21204
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Deletes the following s390x instructions:
- ADDME
- ADDZE
- SUBME
- SUBZE
They appear to be emulated PPC instructions left over from the
porting process and I don't think they will ever be useful.
Change-Id: I9b1ba78019dbd1218d0c8f8ea2903878802d1990
Reviewed-on: https://go-review.googlesource.com/30538
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adds the following instructions and uses them in the SSA backend:
- ANDW
- ORW
- XORW
The instruction encodings for 32-bit operations are typically shorter,
particularly when an immediate is used. For example, XORW $-1, R1
only requires one instruction, whereas XOR requires two.
Also removes some unused instructions (that were emulated):
- ANDN
- NAND
- ORN
- NOR
Change-Id: Iff2a16f52004ba498720034e354be9771b10cac4
Reviewed-on: https://go-review.googlesource.com/30291
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Better to just rematerialize them when needed instead of
cross-register spilling or other techniques for keeping them in
registers.
This helps for amd64 code that does 1 << x. It is better to do
loop:
MOVQ $1, AX // materialize arg to SLLQ
SLLQ CX, AX
...
goto loop
than to do
MOVQ $1, AX // materialize outsize of loop
loop:
MOVQ AX, DX // save value that's about to be clobbered
SLLQ CX, AX
MOVQ DX, AX // move it back to the correct register
goto loop
Update #16092
Change-Id: If7ac290208f513061ebb0736e8a79dcb0ba338c0
Reviewed-on: https://go-review.googlesource.com/30471
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The CgoExternalThreadSIGPROF test starts a thread at constructor time
that does a busy loop. That can throw off some other tests. So only
build that code if testprogcgo is built with the tag threadprof, and
adjust the tests that use that code to pass that build tag.
This revealed that the CgoPprofThread test was not testing what it
should have, as it never actually started the cpuHog thread. It was
passing because of the busy loop thread. Fix it to start the thread as
intended.
Change-Id: I087a9e4fc734a86be16a287456441afac5676beb
Reviewed-on: https://go-review.googlesource.com/30362
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently if you declare a type overwriting a predeclared type
and export methods on it they will be exposed in godoc, even
though the type itself is not exported. This corrects that
by making all methods on these types hidden, since that's
the expected output.
Fixes#9860
Change-Id: I14037bdcef1b4bbefcf299a143bac8bf363718e0
Reviewed-on: https://go-review.googlesource.com/20610
Reviewed-by: Russ Cox <rsc@golang.org>
It is pretty confusing when there are Go files ignored for mismatching
build tags and similar and we output "no buildable Go files" without
giving any other information about some Go files have been ignored.
Fixes#17008.
Change-Id: I1766ee86a9a7a72f6694deae3f73b47bfc9d0be5
Reviewed-on: https://go-review.googlesource.com/29113
Run-TryBot: Jaana Burcu Dogan <jbd@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Suppose you have already downloaded "foo.bar/baz", where the repo
is for all of foo.bar/, and you then "go get -u foo.bar/...".
The command-line wildcard expands to foo.bar/baz,
and go get updates the foo.bar/ repo.
Suppose that the repo update brought in foo.bar/quux,
though, which depends on other.site/bar.
Download does not consider foo.bar/quux, since it's
only looking at foo.bar/baz, so it didn't download other.site/bar.
After the download, we call importPaths(args) to decide what to install.
That call was reevaluating the original wildcard with the new repo
and matching foo.bar/quux, which was missing its dependency
other.site/bar, causing a build failure.
The fix in this CL is to remember the pre-download expansion
of the argument list and pass it to the installer. Then only the things
we tried to download get installed.
The case where foo.bar/ is not even checked out yet continues to work,
because in that case we leave the wildcard in place, and download
reevaluates it during the download.
The fix in this CL may not be the right long-term fix, but it is at least a fix.
It may be that download should be passed all the original wildcards
so that it can reexpand them as new code is downloaded, ideally reaching
a fixed point. That can be left for another day.
In short:
- The problem is that the "install" half of "go get" was trying to install
more than the "download" half was properly downloading.
- The fix in this CL is to install just what was downloaded (install less).
- It may be that a future CL should instead download what will be installed (download more).
Fixes#14450.
Change-Id: Ia1984761d24439549b7cff322bc0dbc262c1a653
Reviewed-on: https://go-review.googlesource.com/19892
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
