Skip to content

G
golang
Switch branch/tag
  1. 11 Oct, 2016 7 commits
    • Russ Cox's avatar
      math/big: move exhaustive tests behind -long flag · 9a8832f1
      Russ Cox authored 
      This way you can still run 'go test' or 'go bench -run Foo'
without wondering why it is taking so very long.

Change-Id: Icfa097a6deb1d6682acb7be9f34729215c29eabb
Reviewed-on: https://go-review.googlesource.com/30707Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      9a8832f1
    • Cherry Zhang's avatar
      cmd/compile: intrinsify math/big.mulWW, divWW on AMD64 · 2756d56c
      Cherry Zhang authored 
      Change-Id: I59f7afa7a5803d19f8b21fe70fc85ef997bb3a85
Reviewed-on: https://go-review.googlesource.com/30542
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      2756d56c
    • Cherry Zhang's avatar
      cmd/link: insert trampolines for too-far jumps on ARM · 7c431cb7
      Cherry Zhang authored 
      ARM direct CALL/JMP instruction has 24 bit offset, which can only
encodes jumps within +/-32M. When the target is too far, the top
bits get truncated and the program jumps wild.

This CL detects too-far jumps and automatically insert trampolines,
currently only internal linking on ARM.

It is necessary to make the following changes to the linker:
- Resolve direct jump relocs when assigning addresses to functions.
  this allows trampoline insertion without moving all code that
  already laid down.
- Lay down packages in dependency order, so that when resolving a
  inter-package direct jump reloc, the target address is already
  known. Intra-package jumps are assumed never too far.
- a linker flag -debugtramp is added for debugging trampolines:
    "-debugtramp=1 -v" prints trampoline debug message
    "-debugtramp=2"    forces all inter-package jump to use
                       trampolines (currently ARM only)
    "-debugtramp=2 -v" does both
- Some data structures are changed for bookkeeping.

On ARM, pseudo DIV/DIVU/MOD/MODU instructions now clobber R8
(unfortunate). In the standard library there is no ARM assembly
code that uses these instructions, and the compiler no longer emits
them (CL 29390).

all.bash passes with -debugtramp=2, except a disassembly test (this
is unavoidable as we changed the instruction).

TBD: debug info of trampolines?

Fixes #17028.

Change-Id: Idcce347ea7e0af77c4079041a160b2f6e114b474
Reviewed-on: https://go-review.googlesource.com/29397Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      7c431cb7
    • Ian Lance Taylor's avatar
      runtime: record current PC for SIGPROF on non-Go thread · d03e8b22
      Ian Lance Taylor authored 
      If we get a SIGPROF on a non-Go thread, and the program has not called
runtime.SetCgoTraceback so we have no way to collect a stack trace, then
record a profile that is just the PC where the signal occurred. That
will at least point the user to the right area.

Retrieving the PC from the sigctxt in a signal handler on a non-G thread
required marking a number of trivial sigctxt methods as nosplit, and,
for extra safety, nowritebarrierrec.

The test shows that the existing test CgoPprofThread test does not test
the stack trace, just the profile signal. Leaving that for later.

Change-Id: I8f8f3ff09ac099fc9d9df94b5a9d210ffc20c4ab
Reviewed-on: https://go-review.googlesource.com/30252
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      d03e8b22
    • Hyang-Ah (Hana) Kim's avatar
      cmd/trace: fix a runnable goroutine count bug · c24cc400
      Hyang-Ah (Hana) Kim authored 
      When starting tracing, EvGoCreate events are added for existing
goroutines that may have been blocking in syscall. EvGoCreate
increments the runnable goroutine count. This change makes the
following EvGoInSyscall event decrement the runnable goroutine count
because we now know that goroutine is in syscall, and not runnable.

Made generateTrace return an error, at any given time, the number
of runnable/running/insyscall goroutines becomes non-negative.

Added a basic test that checks the number of runnable/running
goroutines don't include the goroutines in syscall - the test failed
before this change.

Change-Id: Ib732c382e7bd17158a437576f9d589ab89097ce6
Reviewed-on: https://go-review.googlesource.com/25552
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      c24cc400
    • Alex Brainman's avatar
      runtime/cgo: do not explicitly link msvcrt.dll · dd307da1
      Alex Brainman authored 
      CL 14472 solved issue #12030 by explicitly linking msvcrt.dll
to every cgo executable we build. This CL achieves the same
by manually loading ntdll.dll during startup.

Updates #12030

Change-Id: I5d9cd925ef65cc34c5d4031c750f0f97794529b2
Reviewed-on: https://go-review.googlesource.com/30737
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarMinux Ma <minux@golang.org>
      dd307da1
    • John Dethridge's avatar
      cmd/link: more efficient encoding of DWARF line number information · 8f65379f
      John Dethridge authored 
      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/30577Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      8f65379f
  3. 10 Oct, 2016 5 commits
  5. 09 Oct, 2016 7 commits
  7. 08 Oct, 2016 2 commits
  9. 07 Oct, 2016 11 commits
    • Michael Munday's avatar
      cmd/{asm,compile}: replace TESTB op with CMPWconst on s390x · 45b26a93
      Michael Munday authored 
      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: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      45b26a93
    • Keith Randall's avatar
      cmd/compile: use standard dom tree in nilcheckelim · f4e37c8e
      Keith Randall authored 
      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: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      f4e37c8e
    • Andrew Pogrebnoy's avatar
      cmd/compile: fix choice of phi building algorithm · 433be563
      Andrew Pogrebnoy authored 
      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: 's avatarKeith Randall <khr@golang.org>
      433be563
    • Austin Clements's avatar
      cmd/trace: label mark termination spans as such · 94589054
      Austin Clements authored 
      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/30018Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      94589054
    • Austin Clements's avatar
      cmd/trace: move process-wide GC events to their own row · eed309f5
      Austin Clements authored 
      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/30017Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      eed309f5
    • Austin Clements's avatar
      runtime: make next_gc ^0 when GC is disabled · fa9b57bb
      Austin Clements authored 
      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/30016Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      fa9b57bb
    • Keith Randall's avatar
      test: re-enable live2 test on amd64 · f8a0c15e
      Keith Randall authored 
      Not sure why it was ever disabled (early SSA work?) but it passes now.

Change-Id: I76439cacdbd286ce077f7e08c4d0663396a0cd8f
Reviewed-on: https://go-review.googlesource.com/30672Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      f8a0c15e
    • Keith Randall's avatar
      cmd/compile: do regalloc check only when checkEnabled · 93d5f43a
      Keith Randall authored 
      No point doing this check all the time.

Fixes #15621

Change-Id: I1966c061986fe98fe9ebe146d6b9738c13cef724
Reviewed-on: https://go-review.googlesource.com/30670Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      93d5f43a
    • Russ Cox's avatar
      fmt: document and adjust Scanf space handling to eliminate a few paradoxes · 0db9518a
      Russ Cox authored 
      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/30611Reviewed-by: 's avatarRob Pike <r@golang.org>
      0db9518a
    • Russ Cox's avatar
      fmt: add tests showing current Scanf space handling · 23606c6f
      Russ Cox authored 
      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: 's avatarRob Pike <r@golang.org>
      23606c6f
    • Matthew Dempsky's avatar
      cmd/compile: cache pointer and slice types · 78a267e3
      Matthew Dempsky authored 
      Anonymous pointer and slice types are very common and identical
anyway, so just reuse them rather than allocating new ones everywhere
they appear.

Turns out to be a small code/stack size win because SSA relies on
gc.Type identity for reusing temporary stack slots:

   text	   data	    bss	    dec	    hex	filename
6453005	 231643	 146328	6830976	 683b80	go.old
6446660	 231643	 146328	6824631	 6822b7	go.new

Saves on memory usage during compile time too, and maybe a small CPU
time win, but the benchmarks are pretty noisy:

name       old time/op     new time/op     delta
Template       342ms ± 8%      339ms ± 9%    ~           (p=0.332 n=99+99)
Unicode        183ms ± 9%      181ms ±11%    ~           (p=0.274 n=95+98)
GoTypes        1.05s ± 4%      1.04s ± 3%  -1.22%        (p=0.000 n=97+95)
Compiler       4.49s ± 7%      4.46s ± 6%    ~           (p=0.058 n=96+91)

name       old user-ns/op  new user-ns/op  delta
Template        520M ±17%       522M ±20%    ~          (p=0.544 n=98+100)
Unicode         331M ±27%       327M ±30%    ~           (p=0.615 n=98+98)
GoTypes        1.54G ±10%      1.53G ±12%    ~          (p=0.173 n=99+100)
Compiler       6.33G ±10%      6.33G ±10%    ~           (p=0.682 n=98+98)

name       old alloc/op    new alloc/op    delta
Template      44.5MB ± 0%     44.1MB ± 0%  -0.80%        (p=0.000 n=97+99)
Unicode       37.5MB ± 0%     37.3MB ± 0%  -0.44%       (p=0.000 n=98+100)
GoTypes        126MB ± 0%      124MB ± 0%  -1.41%        (p=0.000 n=98+99)
Compiler       518MB ± 0%      508MB ± 0%  -1.90%       (p=0.000 n=98+100)

name       old allocs/op   new allocs/op   delta
Template        441k ± 0%       434k ± 0%  -1.76%       (p=0.000 n=100+97)
Unicode         368k ± 0%       365k ± 0%  -0.69%        (p=0.000 n=99+99)
GoTypes        1.26M ± 0%      1.23M ± 0%  -2.27%       (p=0.000 n=100+99)
Compiler       4.60M ± 0%      4.46M ± 0%  -2.96%       (p=0.000 n=100+99)

Change-Id: I94abce5c57aed0f9c48f567b3ac24c627d4c7c91
Reviewed-on: https://go-review.googlesource.com/30632
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      78a267e3
  11. 06 Oct, 2016 8 commits