1. 16 Mar, 2017 1 commit
    • Keith Randall's avatar
      cmd/compile: intrinsics for math/bits.TrailingZerosX · d5dc4905
      Keith Randall authored
      Implement math/bits.TrailingZerosX using intrinsics.
      
      Generally reorganize the intrinsic spec a bit.
      The instrinsics data structure is now built at init time.
      This will make doing the other functions in math/bits easier.
      
      Update sys.CtzX to return int instead of uint{64,32} so it
      matches math/bits.TrailingZerosX.
      
      Improve the intrinsics a bit for amd64.  We don't need the CMOV
      for <64 bit versions.
      
      Update #18616
      
      Change-Id: Ic1c5339c943f961d830ae56f12674d7b29d4ff39
      Reviewed-on: https://go-review.googlesource.com/38155
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      d5dc4905
  2. 15 Mar, 2017 10 commits
    • Martin Möhrmann's avatar
      runtime: make complex division c99 compatible · 16200c73
      Martin Möhrmann authored
      - changes tests to check that the real and imaginary part of the go complex
        division result is equal to the result gcc produces for c99
      - changes complex division code to satisfy new complex division test
      - adds float functions isNan, isFinite, isInf, abs and copysign
        in the runtime package
      
      Fixes #14644.
      
      name                   old time/op  new time/op  delta
      Complex128DivNormal-4  21.8ns ± 6%  13.9ns ± 6%  -36.37%  (p=0.000 n=20+20)
      Complex128DivNisNaN-4  14.1ns ± 1%  15.0ns ± 1%   +5.86%  (p=0.000 n=20+19)
      Complex128DivDisNaN-4  12.5ns ± 1%  16.7ns ± 1%  +33.79%  (p=0.000 n=19+20)
      Complex128DivNisInf-4  10.1ns ± 1%  13.0ns ± 1%  +28.25%  (p=0.000 n=20+19)
      Complex128DivDisInf-4  11.0ns ± 1%  20.9ns ± 1%  +90.69%  (p=0.000 n=16+19)
      ComplexAlgMap-4        86.7ns ± 1%  86.8ns ± 2%     ~     (p=0.804 n=20+20)
      
      Change-Id: I261f3b4a81f6cc858bc7ff48f6fd1b39c300abf0
      Reviewed-on: https://go-review.googlesource.com/37441Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      16200c73
    • Austin Clements's avatar
      runtime: print user stack on other threads during GOTRACBEACK=crash · 4b8f41da
      Austin Clements authored
      Currently, when printing tracebacks of other threads during
      GOTRACEBACK=crash, if the thread is on the system stack we print only
      the header for the user goroutine and fail to print its stack. This
      happens because we passed the g0 to traceback instead of curg. The g0
      never has anything set in its gobuf, so traceback doesn't print
      anything.
      
      Fix this by passing _g_.m.curg to traceback instead of the g0.
      
      Fixes #19494.
      
      Change-Id: Idfabf94d6a725e9cdf94a3923dead6455ef3b217
      Reviewed-on: https://go-review.googlesource.com/38012
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      4b8f41da
    • Austin Clements's avatar
      runtime: make GOTRACEBACK=crash crash promptly in cgo binaries · f2e87158
      Austin Clements authored
      GOTRACEBACK=crash works by bouncing a SIGQUIT around the process
      sched.mcount times. However, sched.mcount includes the extra Ms
      allocated by oneNewExtraM for cgo callbacks. Hence, if there are any
      extra Ms that don't have real OS threads, we'll try to send SIGQUIT
      more times than there are threads to catch it. Since nothing will
      catch these extra signals, we'll fall back to blocking for five
      seconds before aborting the process.
      
      Avoid this five second delay by subtracting out the number of extra Ms
      when sending SIGQUITs.
      
      Of course, in a cgo binary, it's still possible for the SIGQUIT to go
      to a cgo thread and cause some other failure mode. This does not fix
      that.
      
      Change-Id: I4fbf3c52dd721812796c4c1dcb2ab4cb7026d965
      Reviewed-on: https://go-review.googlesource.com/38182
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      f2e87158
    • Josh Bleecher Snyder's avatar
      cmd/compile: check labels and gotos before building SSA · c03e75e5
      Josh Bleecher Snyder authored
      This CL introduces yet another compiler pass,
      which checks for correct control flow constructs
      prior to converting from AST to SSA form.
      
      It cannot be integrated with walk, since walk rewrites
      switch and select statements on the fly.
      
      To reduce code duplication, this CL also does some
      minor refactoring.
      
      With this pass in place, the AST to SSA converter
      can now stop generating SSA for any known-dead code.
      This minor savings pays for the minor cost of the new pass.
      
      Performance is almost a wash:
      
      name       old time/op     new time/op     delta
      Template       206ms ± 4%      205ms ± 4%   ~     (p=0.108 n=43+43)
      Unicode       84.0ms ± 4%     84.0ms ± 4%   ~     (p=0.979 n=43+43)
      GoTypes        550ms ± 3%      553ms ± 3%   ~     (p=0.065 n=40+41)
      Compiler       2.57s ± 4%      2.58s ± 2%   ~     (p=0.103 n=44+41)
      SSA            3.94s ± 3%      3.93s ± 2%   ~     (p=0.833 n=44+42)
      Flate          126ms ± 6%      125ms ± 4%   ~     (p=0.941 n=43+39)
      GoParser       147ms ± 4%      148ms ± 3%   ~     (p=0.164 n=42+39)
      Reflect        359ms ± 3%      357ms ± 5%   ~     (p=0.241 n=43+44)
      Tar            106ms ± 5%      106ms ± 7%   ~     (p=0.853 n=40+43)
      XML            202ms ± 3%      203ms ± 3%   ~     (p=0.488 n=42+41)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        240M ± 4%       239M ± 4%   ~     (p=0.844 n=42+43)
      Unicode         107M ± 5%       107M ± 4%   ~     (p=0.332 n=40+43)
      GoTypes         735M ± 3%       731M ± 4%   ~     (p=0.141 n=43+44)
      Compiler       3.51G ± 3%      3.52G ± 3%   ~     (p=0.208 n=42+43)
      SSA            5.72G ± 4%      5.72G ± 3%   ~     (p=0.928 n=44+42)
      Flate           151M ± 7%       150M ± 8%   ~     (p=0.662 n=44+43)
      GoParser        181M ± 5%       181M ± 4%   ~     (p=0.379 n=41+44)
      Reflect         447M ± 4%       445M ± 4%   ~     (p=0.344 n=43+43)
      Tar             125M ± 7%       124M ± 6%   ~     (p=0.353 n=43+43)
      XML             248M ± 4%       250M ± 6%   ~     (p=0.158 n=44+44)
      
      name       old alloc/op    new alloc/op    delta
      Template      40.3MB ± 0%     40.2MB ± 0%  -0.27%  (p=0.000 n=10+10)
      Unicode       30.3MB ± 0%     30.2MB ± 0%  -0.10%  (p=0.015 n=10+10)
      GoTypes        114MB ± 0%      114MB ± 0%  -0.06%  (p=0.000 n=7+9)
      Compiler       480MB ± 0%      481MB ± 0%  +0.07%  (p=0.000 n=10+10)
      SSA            864MB ± 0%      862MB ± 0%  -0.25%  (p=0.000 n=9+10)
      Flate         25.9MB ± 0%     25.9MB ± 0%    ~     (p=0.123 n=10+10)
      GoParser      32.1MB ± 0%     32.1MB ± 0%    ~     (p=0.631 n=10+10)
      Reflect       79.9MB ± 0%     79.6MB ± 0%  -0.39%  (p=0.000 n=10+9)
      Tar           27.1MB ± 0%     27.0MB ± 0%  -0.18%  (p=0.003 n=10+10)
      XML           42.6MB ± 0%     42.6MB ± 0%    ~     (p=0.143 n=10+10)
      
      name       old allocs/op   new allocs/op   delta
      Template        401k ± 0%       401k ± 1%    ~     (p=0.353 n=10+10)
      Unicode         322k ± 0%       322k ± 0%    ~     (p=0.739 n=10+10)
      GoTypes        1.18M ± 0%      1.18M ± 0%  +0.25%  (p=0.001 n=7+8)
      Compiler       4.51M ± 0%      4.53M ± 0%  +0.37%  (p=0.000 n=10+10)
      SSA            7.91M ± 0%      7.93M ± 0%  +0.20%  (p=0.000 n=9+10)
      Flate           244k ± 0%       245k ± 0%    ~     (p=0.123 n=10+10)
      GoParser        323k ± 1%       324k ± 1%  +0.40%  (p=0.035 n=10+10)
      Reflect        1.01M ± 0%      1.02M ± 0%  +0.37%  (p=0.000 n=10+9)
      Tar             258k ± 1%       258k ± 1%    ~     (p=0.661 n=10+9)
      XML             403k ± 0%       405k ± 0%  +0.47%  (p=0.004 n=10+10)
      
      Updates #15756
      Updates #19250
      
      Change-Id: I647bfbb745c35630447eb79dfcaa994b490ce942
      Reviewed-on: https://go-review.googlesource.com/38159
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      c03e75e5
    • Josh Bleecher Snyder's avatar
      cmd/compile: ensure TESTQconst AuxInt is in range · 604455a4
      Josh Bleecher Snyder authored
      Fixes #19555
      
      Change-Id: I7aa0551a90f6bb630c0ba721f3525a8a9cf793fd
      Reviewed-on: https://go-review.googlesource.com/38164
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      604455a4
    • Bryan C. Mills's avatar
      archive/zip: parallelize benchmarks · d0a045da
      Bryan C. Mills authored
      Add subbenchmarks for BenchmarkZip64Test with different sizes to tease
      apart construction costs vs. steady-state throughput.
      
      Results remain comparable with the non-parallel version with -cpu=1:
      
      benchmark                           old ns/op     new ns/op     delta
      BenchmarkCompressedZipGarbage       26832835      27506953      +2.51%
      BenchmarkCompressedZipGarbage-6     27172377      4321534       -84.10%
      BenchmarkZip64Test                  196758732     197765510     +0.51%
      BenchmarkZip64Test-6                193850605     192625458     -0.63%
      
      benchmark                           old allocs     new allocs     delta
      BenchmarkCompressedZipGarbage       44             44             +0.00%
      BenchmarkCompressedZipGarbage-6     44             44             +0.00%
      
      benchmark                           old bytes     new bytes     delta
      BenchmarkCompressedZipGarbage       5592          5664          +1.29%
      BenchmarkCompressedZipGarbage-6     5592          21946         +292.45%
      
      updates #18177
      
      Change-Id: Icfa359d9b1a8df5e085dacc07d2b9221b284764c
      Reviewed-on: https://go-review.googlesource.com/36719Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      d0a045da
    • Cherry Zhang's avatar
      cmd/link: on PPC64, put plt stubs at beginning of Textp · 15b37655
      Cherry Zhang authored
      Put call stubs at the beginning (instead of the end). So the
      trampoline pass knows the addresses of the stubs, and it can
      insert trampolines when necessary.
      
      Fixes #19425.
      
      Change-Id: I1e06529ef837a6130df58917315610d45a6819ca
      Reviewed-on: https://go-review.googlesource.com/38131
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarLynn Boger <laboger@linux.vnet.ibm.com>
      15b37655
    • Josh Bleecher Snyder's avatar
      cmd/compile: define roles for ssa.Func, ssa.Config, and ssa.Cache · 43afcb5c
      Josh Bleecher Snyder authored
      The line between ssa.Func and ssa.Config has blurred.
      Concurrent compilation in the backend will require more precision.
      This CL lays out an (aspirational) organization.
      The implementation will come in follow-up CLs,
      once the organization is settled.
      
      ssa.Config holds basic compiler configuration,
      mostly arch-specific information.
      It is configured once, early on, and is readonly,
      so it is safe for concurrent use.
      
      ssa.Func is a single-shot object used for
      compiling a single Func. It is not concurrency-safe
      and not re-usable.
      
      ssa.Cache is a multi-use object used to avoid
      expensive allocations during compilation.
      Each ssa.Func is given an ssa.Cache to use.
      ssa.Cache is not concurrency-safe.
      
      Change-Id: Id02809b6f3541541cac6c27bbb598834888ce1cc
      Reviewed-on: https://go-review.googlesource.com/38160Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      43afcb5c
    • David Chase's avatar
      cmd/compile: put spills in better places · 886e9e60
      David Chase authored
      Previously we always issued a spill right after the op
      that was being spilled.  This CL pushes spills father away
      from the generator, hopefully pushing them into unlikely branches.
      For example:
      
        x = ...
        if unlikely {
          call ...
        }
        ... use x ...
      
      Used to compile to
      
        x = ...
        spill x
        if unlikely {
          call ...
          restore x
        }
      
      It now compiles to
      
        x = ...
        if unlikely {
          spill x
          call ...
          restore x
        }
      
      This is particularly useful for code which appends, as the only
      call is an unlikely call to growslice.  It also helps for the
      spills needed around write barrier calls.
      
      The basic algorithm is walk down the dominator tree following a
      path where the block still dominates all of the restores.  We're
      looking for a block that:
       1) dominates all restores
       2) has the value being spilled in a register
       3) has a loop depth no deeper than the value being spilled
      
      The walking-down code is iterative.  I was forced to limit it to
      searching 100 blocks so it doesn't become O(n^2).  Maybe one day
      we'll find a better way.
      
      I had to delete most of David's code which pushed spills out of loops.
      I suspect this CL subsumes most of the cases that his code handled.
      
      Generally positive performance improvements, but hard to tell for sure
      with all the noise.  (compilebench times are unchanged.)
      
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.91s ±15%     2.80s ±12%    ~     (p=0.063 n=10+10)
      Fannkuch11-12                3.47s ± 0%     3.30s ± 4%  -4.91%   (p=0.000 n=9+10)
      FmtFprintfEmpty-12          48.0ns ± 1%    47.4ns ± 1%  -1.32%    (p=0.002 n=9+9)
      FmtFprintfString-12         85.6ns ±11%    79.4ns ± 3%  -7.27%  (p=0.005 n=10+10)
      FmtFprintfInt-12            91.8ns ±10%    85.9ns ± 4%    ~      (p=0.203 n=10+9)
      FmtFprintfIntInt-12          135ns ±13%     127ns ± 1%  -5.72%   (p=0.025 n=10+9)
      FmtFprintfPrefixedInt-12     167ns ± 1%     168ns ± 2%    ~      (p=0.580 n=9+10)
      FmtFprintfFloat-12           249ns ±11%     230ns ± 1%  -7.32%  (p=0.000 n=10+10)
      FmtManyArgs-12               504ns ± 7%     506ns ± 1%    ~       (p=0.198 n=9+9)
      GobDecode-12                6.95ms ± 1%    7.04ms ± 1%  +1.37%  (p=0.001 n=10+10)
      GobEncode-12                6.32ms ±13%    6.04ms ± 1%    ~     (p=0.063 n=10+10)
      Gzip-12                      233ms ± 1%     235ms ± 0%  +1.01%   (p=0.000 n=10+9)
      Gunzip-12                   40.1ms ± 1%    39.6ms ± 0%  -1.12%   (p=0.000 n=10+8)
      HTTPClientServer-12          227µs ± 9%     221µs ± 5%    ~       (p=0.114 n=9+8)
      JSONEncode-12               16.1ms ± 2%    15.8ms ± 1%  -2.09%    (p=0.002 n=9+8)
      JSONDecode-12               61.8ms ±11%    57.9ms ± 1%  -6.30%   (p=0.000 n=10+9)
      Mandelbrot200-12            4.30ms ± 3%    4.28ms ± 1%    ~      (p=0.203 n=10+8)
      GoParse-12                  3.18ms ± 2%    3.18ms ± 2%    ~     (p=0.579 n=10+10)
      RegexpMatchEasy0_32-12      76.7ns ± 1%    77.5ns ± 1%  +0.92%    (p=0.002 n=9+8)
      RegexpMatchEasy0_1K-12       239ns ± 3%     239ns ± 1%    ~     (p=0.204 n=10+10)
      RegexpMatchEasy1_32-12      71.4ns ± 1%    70.6ns ± 0%  -1.15%   (p=0.000 n=10+9)
      RegexpMatchEasy1_1K-12       383ns ± 2%     390ns ±10%    ~       (p=0.181 n=8+9)
      RegexpMatchMedium_32-12      114ns ± 0%     113ns ± 1%  -0.88%    (p=0.000 n=9+8)
      RegexpMatchMedium_1K-12     36.3µs ± 1%    36.8µs ± 1%  +1.59%   (p=0.000 n=10+8)
      RegexpMatchHard_32-12       1.90µs ± 1%    1.90µs ± 1%    ~     (p=0.341 n=10+10)
      RegexpMatchHard_1K-12       59.4µs ±11%    57.8µs ± 1%    ~      (p=0.968 n=10+9)
      Revcomp-12                   461ms ± 1%     462ms ± 1%    ~       (p=1.000 n=9+9)
      Template-12                 67.5ms ± 1%    66.3ms ± 1%  -1.77%   (p=0.000 n=10+8)
      TimeParse-12                 314ns ± 3%     309ns ± 0%  -1.56%    (p=0.000 n=9+8)
      TimeFormat-12                340ns ± 2%     331ns ± 1%  -2.79%  (p=0.000 n=10+10)
      
      The go binary is 0.2% larger.  Not really sure why the size
      would change.
      
      Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c
      Reviewed-on: https://go-review.googlesource.com/34822Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      886e9e60
    • Philip Hofer's avatar
      cmd/compile/internal/gc: mark generated wrappers as DUPOK · 710f4d3e
      Philip Hofer authored
      Interface wrapper functions now get compiled eagerly in some cases.
      Consequently, they may be present in multiple translation units.
      Mark them as DUPOK, just like closures.
      
      Fixes #19548
      Fixes #19550
      
      Change-Id: Ibe74adb5a62dbf6447db37fde22dcbb3479969ef
      Reviewed-on: https://go-review.googlesource.com/38156Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      710f4d3e
  3. 14 Mar, 2017 19 commits
  4. 13 Mar, 2017 10 commits
    • Hugues Bruant's avatar
      runtime: add mapassign_fast* · ec091b6a
      Hugues Bruant authored
      Add benchmarks for map assignment with int32/int64/string key
      
      Benchmark results on darwin/amd64
      
      name                  old time/op  new time/op  delta
      MapAssignInt32_255-8  24.7ns ± 3%  17.4ns ± 2%  -29.75%  (p=0.000 n=10+10)
      MapAssignInt32_64k-8  45.5ns ± 4%  37.6ns ± 4%  -17.18%  (p=0.000 n=10+10)
      MapAssignInt64_255-8  26.0ns ± 3%  17.9ns ± 4%  -31.03%  (p=0.000 n=10+10)
      MapAssignInt64_64k-8  46.9ns ± 5%  38.7ns ± 2%  -17.53%  (p=0.000 n=9+10)
      MapAssignStr_255-8    47.8ns ± 3%  24.8ns ± 4%  -48.01%  (p=0.000 n=10+10)
      MapAssignStr_64k-8    83.0ns ± 3%  51.9ns ± 3%  -37.45%  (p=0.000 n=10+9)
      
      name                     old time/op    new time/op    delta
      BinaryTree17-8              3.11s ±19%     2.78s ± 3%    ~     (p=0.095 n=5+5)
      Fannkuch11-8                3.26s ± 1%     3.21s ± 2%    ~     (p=0.056 n=5+5)
      FmtFprintfEmpty-8          50.3ns ± 1%    50.8ns ± 2%    ~     (p=0.246 n=5+5)
      FmtFprintfString-8         82.7ns ± 4%    80.1ns ± 5%    ~     (p=0.238 n=5+5)
      FmtFprintfInt-8            82.6ns ± 2%    81.9ns ± 3%    ~     (p=0.508 n=5+5)
      FmtFprintfIntInt-8          124ns ± 4%     121ns ± 3%    ~     (p=0.111 n=5+5)
      FmtFprintfPrefixedInt-8     158ns ± 6%     160ns ± 2%    ~     (p=0.341 n=5+5)
      FmtFprintfFloat-8           249ns ± 2%     245ns ± 2%    ~     (p=0.095 n=5+5)
      FmtManyArgs-8               513ns ± 2%     519ns ± 3%    ~     (p=0.151 n=5+5)
      GobDecode-8                7.48ms ±12%    7.11ms ± 2%    ~     (p=0.222 n=5+5)
      GobEncode-8                6.25ms ± 1%    6.03ms ± 2%  -3.56%  (p=0.008 n=5+5)
      Gzip-8                      252ms ± 4%     252ms ± 4%    ~     (p=1.000 n=5+5)
      Gunzip-8                   38.4ms ± 3%    38.6ms ± 2%    ~     (p=0.690 n=5+5)
      HTTPClientServer-8         76.9µs ±41%    66.4µs ± 6%    ~     (p=0.310 n=5+5)
      JSONEncode-8               16.5ms ± 3%    16.7ms ± 3%    ~     (p=0.421 n=5+5)
      JSONDecode-8               54.6ms ± 1%    54.3ms ± 2%    ~     (p=0.548 n=5+5)
      Mandelbrot200-8            4.45ms ± 3%    4.47ms ± 1%    ~     (p=0.841 n=5+5)
      GoParse-8                  3.43ms ± 1%    3.32ms ± 2%  -3.28%  (p=0.008 n=5+5)
      RegexpMatchEasy0_32-8      88.2ns ± 3%    89.4ns ± 2%    ~     (p=0.333 n=5+5)
      RegexpMatchEasy0_1K-8       205ns ± 1%     206ns ± 1%    ~     (p=0.905 n=5+5)
      RegexpMatchEasy1_32-8      85.1ns ± 1%    85.5ns ± 5%    ~     (p=0.690 n=5+5)
      RegexpMatchEasy1_1K-8       365ns ± 1%     371ns ± 9%    ~     (p=1.000 n=5+5)
      RegexpMatchMedium_32-8      129ns ± 2%     128ns ± 3%    ~     (p=0.730 n=5+5)
      RegexpMatchMedium_1K-8     39.8µs ± 0%    39.7µs ± 4%    ~     (p=0.730 n=4+5)
      RegexpMatchHard_32-8       1.99µs ± 3%    2.05µs ±16%    ~     (p=0.794 n=5+5)
      RegexpMatchHard_1K-8       59.3µs ± 1%    60.3µs ± 7%    ~     (p=1.000 n=5+5)
      Revcomp-8                   1.36s ±63%     0.52s ± 5%    ~     (p=0.095 n=5+5)
      Template-8                 62.6ms ±14%    60.5ms ± 5%    ~     (p=0.690 n=5+5)
      TimeParse-8                 330ns ± 2%     324ns ± 2%    ~     (p=0.087 n=5+5)
      TimeFormat-8                350ns ± 3%     340ns ± 1%  -2.86%  (p=0.008 n=5+5)
      
      name                     old speed      new speed      delta
      GobDecode-8               103MB/s ±11%   108MB/s ± 2%    ~     (p=0.222 n=5+5)
      GobEncode-8               123MB/s ± 1%   127MB/s ± 2%  +3.71%  (p=0.008 n=5+5)
      Gzip-8                   77.1MB/s ± 4%  76.9MB/s ± 3%    ~     (p=1.000 n=5+5)
      Gunzip-8                  505MB/s ± 3%   503MB/s ± 2%    ~     (p=0.690 n=5+5)
      JSONEncode-8              118MB/s ± 3%   116MB/s ± 3%    ~     (p=0.421 n=5+5)
      JSONDecode-8             35.5MB/s ± 1%  35.8MB/s ± 2%    ~     (p=0.397 n=5+5)
      GoParse-8                16.9MB/s ± 1%  17.4MB/s ± 2%  +3.45%  (p=0.008 n=5+5)
      RegexpMatchEasy0_32-8     363MB/s ± 3%   358MB/s ± 2%    ~     (p=0.421 n=5+5)
      RegexpMatchEasy0_1K-8    4.98GB/s ± 1%  4.97GB/s ± 1%    ~     (p=0.548 n=5+5)
      RegexpMatchEasy1_32-8     376MB/s ± 1%   375MB/s ± 5%    ~     (p=0.690 n=5+5)
      RegexpMatchEasy1_1K-8    2.80GB/s ± 1%  2.76GB/s ± 9%    ~     (p=0.841 n=5+5)
      RegexpMatchMedium_32-8   7.73MB/s ± 1%  7.76MB/s ± 3%    ~     (p=0.730 n=5+5)
      RegexpMatchMedium_1K-8   25.8MB/s ± 0%  25.8MB/s ± 4%    ~     (p=0.651 n=4+5)
      RegexpMatchHard_32-8     16.1MB/s ± 3%  15.7MB/s ±14%    ~     (p=0.794 n=5+5)
      RegexpMatchHard_1K-8     17.3MB/s ± 1%  17.0MB/s ± 7%    ~     (p=0.984 n=5+5)
      Revcomp-8                 273MB/s ±83%   488MB/s ± 5%    ~     (p=0.095 n=5+5)
      Template-8               31.1MB/s ±13%  32.1MB/s ± 5%    ~     (p=0.690 n=5+5)
      
      Updates #19495
      
      Change-Id: I116e9a2a4594769318b22d736464de8a98499909
      Reviewed-on: https://go-review.googlesource.com/38091Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      ec091b6a
    • Aliaksandr Valialkin's avatar
      cmd/vet: check shift calculations with "unsafe" package · 53937aad
      Aliaksandr Valialkin authored
      vet should properly handle shift calculations via "unsafe"
      package after the CL 37950.
      
      Change-Id: I7737f2e656a5166337a17b92db46a0997f2a4e0e
      Reviewed-on: https://go-review.googlesource.com/38064Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      53937aad
    • Matthew Dempsky's avatar
      cmd/compile/internal/ssa: make ARM's udiv like other calls · cc71aa9a
      Matthew Dempsky authored
      Passes toolstash-check -all.
      
      Change-Id: Id389f8158cf33a3c0fcef373615b5351e7c74b5b
      Reviewed-on: https://go-review.googlesource.com/38082
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      cc71aa9a
    • David Chase's avatar
      Revert "cmd/compile: de-virtualize interface calls" · b59a4056
      David Chase authored
      This reverts commit 4e0c7c3f.
      
      Reason for revert: The presence-of-optimization test program is fragile, breaks under noopt, and might break if the Go libraries are tweaked.  It needs to be (re)written without reference to other packages.
      
      Change-Id: I3aaf1ab006a1a255f961a978e9c984341740e3c7
      Reviewed-on: https://go-review.googlesource.com/38097Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      b59a4056
    • Matthew Dempsky's avatar
      cmd/compile/internal/gc: refactor ACALL Prog creation · 118b3fe7
      Matthew Dempsky authored
      This abstracts creation of ACALL Progs into package gc. The main
      benefit of this today is we can refactor away a lot of common
      boilerplate code.
      
      Later, once liveness analysis happens on the SSA graph, this will also
      provide an easy insertion point for emitting the PCDATA Progs
      immediately before call instructions.
      
      Passes toolstash-check -all.
      
      Change-Id: Ia15108ace97201cd84314f1ca916dfeb4f09d61c
      Reviewed-on: https://go-review.googlesource.com/38081Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      118b3fe7
    • Alberto Donizetti's avatar
      encoding/gob: add Encode-Decode Int slices tests · 2e7c3b3f
      Alberto Donizetti authored
      Tinkering with the gob package shows that is currently possible to
      *completely destroy* Int slices encoding without triggering a single
      test failure.
      
      The various encInt{8,16,32,64}Slice methods are only called during the
      execution of the GobMapInterfaceEncode test, which only encodes a few
      slices of length exactly 1 and then just checks that the error
      returned by Encode is nil (without trying to Decode back the data).
      
      This patch adds a few tests for signed integer slices encoding.
      
      Change-Id: Ifaaee2f32132873118b241f79aa8203e4ad31416
      Reviewed-on: https://go-review.googlesource.com/38066Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      2e7c3b3f
    • Matthew Dempsky's avatar
      cmd/compile/internal/ssa: replace {Defer,Go}Call with StaticCall · 08d8d5c9
      Matthew Dempsky authored
      Passes toolstash-check -all.
      
      Change-Id: Icf8b75364e4761a5e56567f503b2c1cb17382ed2
      Reviewed-on: https://go-review.googlesource.com/38080
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      08d8d5c9
    • khr's avatar
      cmd/compile: zero return parameters earlier · a51e4cc9
      khr authored
      Move the zeroing of results earlier.  In particular, they need to
      come before any move-to-heap operations, as those require allocation.
      Those allocations are points at which the GC can see the uninitialized
      result slots.
      
      For the function:
      
      func f() (x, y, z *int) {
        defer(){}()
        escape(&y)
        return
      }
      
      We used to generate code like this:
      
      x = nil
      y = nil
      &y = new(int)
      z = nil
      
      Now we will generate:
      
      x = nil
      y = nil
      z = nil
      &y = new(int)
      
      Since the fix for #18860, the return slots are always live if there
      is a defer, so the former ordering allowed the GC to see junk
      in the z slot.
      
      Fixes #19078
      
      Change-Id: I71554ae437549725bb79e13b2c100b2911d47ed4
      Reviewed-on: https://go-review.googlesource.com/38133
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      a51e4cc9
    • Ilya Tocar's avatar
      cmd/internal/obj/x86: remove unused const · 27492a2a
      Ilya Tocar authored
      Since https://go-review.googlesource.com/24040 we no longer pad functions
      in asm6, so funcAlign is unused. Delete it.
      
      Change-Id: Id710e545a76b1797398f2171fe7e0928811fcb31
      Reviewed-on: https://go-review.googlesource.com/38134Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      27492a2a
    • Josh Bleecher Snyder's avatar
      cmd/compile: eliminate more nil checks of phis · c694f6f3
      Josh Bleecher Snyder authored
      The existing implementation started by eliminating
      nil checks for OpAddr, OpAddPtr, and OpPhis with
      all non-nil args.
      
      However, some OpPhis had all non-nil args,
      but their args had not been processed yet.
      
      Pull the OpPhi checks into their own loop,
      and repeat until stabilization.
      
      Eliminates a dozen additional nilchecks during make.bash.
      
      Negligible compiler performance impact.
      
      Change-Id: If7b803c3ad7582af7d9867d05ca13e03e109d864
      Reviewed-on: https://go-review.googlesource.com/37999
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      c694f6f3