1. 15 May, 2017 7 commits
    • David Chase's avatar
      cmd/compile: don't attach lines to SB, SP, similar constants · 27da3ba5
      David Chase authored
      Attaching positions to SB, SP, initial mem can result in
      less-good line-numbering when compiled for debugging.
      This "fix" also removes source position from a zero-valued
      struct (but not from its fields) and from a zero-length
      array constant.
      
      This may be a general problem for constants in entry blocks.
      
      Fixes #20367.
      
      Change-Id: I7e9df3341be2e2f60f127d35bb31e43cdcfce9a1
      Reviewed-on: https://go-review.googlesource.com/43531
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      27da3ba5
    • Keith Randall's avatar
      cmd/compile: better check for single live memory · 256210c7
      Keith Randall authored
      Enhance the one-live-memory-at-a-time check to run during many
      more phases of the SSA backend. Also make it work in an interblock
      fashion.
      
      Change types.IsMemory to return true for tuples containing a memory type.
      
      Fix trim pass to build the merged phi correctly. Doesn't affect
      code but allows the check to pass after trim runs.
      
      Switch the AddTuple* ops to take the memory-containing tuple argument second.
      
      Update #20335
      
      Change-Id: I5b03ef3606b75a9e4f765276bb8b183cdc172b43
      Reviewed-on: https://go-review.googlesource.com/43495
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      256210c7
    • Josh Bleecher Snyder's avatar
      test: add test of deferred delete · d5e01c04
      Josh Bleecher Snyder authored
      Updates #19710
      
      Change-Id: I37d19a4a02b9010cb5f9062b3d141d5d65e12e01
      Reviewed-on: https://go-review.googlesource.com/43497
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      d5e01c04
    • Dmitri Shuralyov's avatar
      go/build: return partial information on Import error, for local import paths · 67e47124
      Dmitri Shuralyov authored
      Documentation of build.Import says:
      
      	// If the path is a local import path naming a package that can be imported
      	// using a standard import path, the returned package will set p.ImportPath
      	// to that path.
      	// ...
      	// If an error occurs, Import returns a non-nil error and a non-nil
      	// *Package containing partial information.
      
      That behavior was previously untested, and broken by change in CL 33158.
      
      Fix that by avoiding returning early on error for local import paths.
      First, gather partial information, and only then check that the p.Dir
      directory exists.
      
      Add tests for this behavior.
      
      Fixes #19769.
      Fixes #20175 (duplicate of #19769).
      Updates #17863.
      
      Change-Id: I169cb35291099d05e02aaa3cb23a7403d1cc3657
      Reviewed-on: https://go-review.googlesource.com/42350Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      67e47124
    • Austin Clements's avatar
      runtime/pprof: expand inlined frames in symbolized proto profiles · 9e83c11f
      Austin Clements authored
      Currently proto symbolization uses runtime.FuncForPC and assumes each
      PC maps to a single frame. This isn't true in the presence of inlining
      (even with leaf-only inlining this can get incorrect results).
      
      Change PC symbolization to use runtime.CallersFrames to expand each PC
      to all of the frames at that PC.
      
      Change-Id: I8d20dff7495a5de495ae07f569122c225d433ced
      Reviewed-on: https://go-review.googlesource.com/41256
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMichael Matloob <matloob@golang.org>
      9e83c11f
    • Austin Clements's avatar
      runtime/pprof: clean up call/return PCs in memory profiles · 1dc0f969
      Austin Clements authored
      Proto profile conversion is inconsistent about call vs return PCs in
      profile locations. The proto defines locations to be call PCs. This is
      what we do when proto-izing CPU profiles, but we fail to convert the
      return PCs in memory and count profile stacks to call PCs when
      converting them to proto locations.
      
      Fix this in the heap and count profile conversion functions.
      TestConvertMemProfile also hard-codes this failure to convert from
      return PCs to call PCs, so fix up the addresses in the synthesized
      profile to be return PCs while checking that we get call PCs out of
      the conversion.
      
      Change-Id: If1fc028b86fceac6d71a2d9fa6c41ff442c89296
      Reviewed-on: https://go-review.googlesource.com/42951
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMichael Matloob <matloob@golang.org>
      1dc0f969
    • Alex Brainman's avatar
      cmd/link: actually generate .debug_gdb_scripts section on windows · 1d44c4e3
      Alex Brainman authored
      Adjust finddebugruntimepath to look for runtime/debug.go file
      instead of runtime/runtime.go. This actually finds runtime.GOMAXPROCS
      in every Go executable (including windows).
      
      I also included "-Wl,-T,fix_debug_gdb_scripts.ld" parameter to gcc
      invocation on windows to work around gcc bug (see #20183 for details).
      
      This CL only fixes windows -buildmode=exe, buildmode=c-archive
      is still broken.
      
      Thanks to Egon Elbre and Nick Clifton for investigation.
      
      Fixes #20183
      Fixes #20218
      
      Change-Id: I5369a4db3913226aef3d9bd6317446856b0a1c34
      Reviewed-on: https://go-review.googlesource.com/43331Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      1d44c4e3
  2. 14 May, 2017 3 commits
    • Robert Griesemer's avatar
      text/scanner: clarify documentation on Pos and Position · fca6ad45
      Robert Griesemer authored
      For #20292. (See discussion in that issue.)
      
      Change-Id: I44cd69394fc47a01776905ec34305ba524c89883
      Reviewed-on: https://go-review.googlesource.com/43452Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      fca6ad45
    • Josh Bleecher Snyder's avatar
      cmd/compile: tweak ssa.html colors · cfae61b6
      Josh Bleecher Snyder authored
      Make yellow the last highlight color rather than the first.
      Yellow is also the color that Chrome uses to highlight
      search results, which can be confusing.
      Also, when Night Shift is on on macOS,
      yellow highlighting is completely invisible.
      I suppose should be sleeping instead.
      
      Also, remove a completed TODO.
      
      Change-Id: I0eb4439272fad9ccb5fe8e2cf409fdd5dc15b26e
      Reviewed-on: https://go-review.googlesource.com/43463
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      cfae61b6
    • Josh Bleecher Snyder's avatar
      cmd/compile: don't update outer variables after capturevars is complete · 61336b78
      Josh Bleecher Snyder authored
      When compiling concurrently, we walk all functions before compiling
      any of them. Walking functions can cause variables to switch from
      being non-addrtaken to addrtaken, e.g. to prepare for a runtime call.
      Typechecking propagates addrtaken-ness of closure variables to
      their outer variables, so that capturevars can decide whether to
      pass the variable's value or a pointer to it.
      
      When all functions are compiled immediately, as long as the containing
      function is compiled prior to the closure, this propagation has no effect.
      When compilation is deferred, though, in rare cases, this results in 
      a change in the addrtaken-ness of a variable in the outer function,
      which in turn changes the compiler's output.
      (This is rare because in a great many cases, a temporary has been
      introduced, insulating the outer variable from modification.)
      But concurrent compilation must generate identical results.
      
      To fix this, track whether capturevars has run.
      If it has, there is no need to update outer variables
      when closure variables change.
      Capturevars always runs before any functions are walked or compiled.
      
      The remainder of the changes in this CL are to support the test.
      In particular, -d=compilelater forces the compiler to walk all
      functions before compiling any of them, despite being non-concurrent.
      This is useful because -live is fundamentally incompatible with
      concurrent compilation, but we want -c=1 to have no behavior changes.
      
      Fixes #20250
      
      Change-Id: I89bcb54268a41e8588af1ac8cc37fbef856a90c2
      Reviewed-on: https://go-review.googlesource.com/42853
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      61336b78
  3. 13 May, 2017 3 commits
  4. 12 May, 2017 7 commits
  5. 11 May, 2017 7 commits
    • Keith Randall's avatar
      cmd/compile: fix store chain in schedule pass · 978af9c2
      Keith Randall authored
      Tuple ops are weird. They are essentially a pair of ops,
      one which consumes a mem and one which generates a mem (the Select1).
      The schedule pass didn't handle these quite right.
      
      Fix the scheduler to include both parts of the paired op in
      the store chain. That makes sure that loads are correctly ordered
      with respect to the first of the pair.
      
      Add a check for the ssacheck builder, that there is only one
      live store at a time. I thought we already had such a check, but
      apparently not...
      
      Fixes #20335
      
      Change-Id: I59eb3446a329100af38d22820b1ca2190ca46a78
      Reviewed-on: https://go-review.googlesource.com/43294
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      978af9c2
    • Josh Bleecher Snyder's avatar
      cmd/compile: restore panic deduplication · e5bb5e39
      Josh Bleecher Snyder authored
      The switch to detailed position information broke
      the removal of duplicate panics on the same line.
      Restore it.
      
      Neutral compiler performance impact:
      
      name        old alloc/op      new alloc/op      delta
      Template         38.8MB ± 0%       38.8MB ± 0%    ~     (p=0.690 n=5+5)
      Unicode          28.7MB ± 0%       28.7MB ± 0%  +0.13%  (p=0.032 n=5+5)
      GoTypes           109MB ± 0%        109MB ± 0%    ~     (p=1.000 n=5+5)
      Compiler          457MB ± 0%        457MB ± 0%    ~     (p=0.151 n=5+5)
      SSA              1.09GB ± 0%       1.10GB ± 0%  +0.17%  (p=0.008 n=5+5)
      Flate            24.6MB ± 0%       24.5MB ± 0%  -0.35%  (p=0.008 n=5+5)
      GoParser         30.9MB ± 0%       31.0MB ± 0%    ~     (p=0.421 n=5+5)
      Reflect          73.4MB ± 0%       73.4MB ± 0%    ~     (p=0.056 n=5+5)
      Tar              25.6MB ± 0%       25.5MB ± 0%  -0.61%  (p=0.008 n=5+5)
      XML              40.9MB ± 0%       40.9MB ± 0%    ~     (p=0.841 n=5+5)
      [Geo mean]       71.6MB            71.6MB       -0.07%
      
      name        old allocs/op     new allocs/op     delta
      Template           394k ± 0%         395k ± 1%    ~     (p=0.151 n=5+5)
      Unicode            343k ± 0%         344k ± 0%  +0.38%  (p=0.032 n=5+5)
      GoTypes           1.16M ± 0%        1.16M ± 0%    ~     (p=1.000 n=5+5)
      Compiler          4.41M ± 0%        4.42M ± 0%    ~     (p=0.151 n=5+5)
      SSA               9.79M ± 0%        9.79M ± 0%    ~     (p=0.690 n=5+5)
      Flate              238k ± 1%         238k ± 0%    ~     (p=0.151 n=5+5)
      GoParser           321k ± 0%         321k ± 1%    ~     (p=0.548 n=5+5)
      Reflect            958k ± 0%         957k ± 0%    ~     (p=0.841 n=5+5)
      Tar                252k ± 0%         252k ± 1%    ~     (p=0.151 n=5+5)
      XML                401k ± 0%         400k ± 0%    ~     (p=1.000 n=5+5)
      [Geo mean]         741k              742k       +0.08%
      
      
      Reduces object files a little bit:
      
      name        old object-bytes  new object-bytes  delta
      Template           386k ± 0%         386k ± 0%  -0.04%  (p=0.008 n=5+5)
      Unicode            202k ± 0%         202k ± 0%    ~     (all equal)
      GoTypes           1.16M ± 0%        1.16M ± 0%  -0.04%  (p=0.008 n=5+5)
      Compiler          3.91M ± 0%        3.91M ± 0%  -0.08%  (p=0.008 n=5+5)
      SSA               7.91M ± 0%        7.91M ± 0%  -0.04%  (p=0.008 n=5+5)
      Flate              228k ± 0%         227k ± 0%  -0.28%  (p=0.008 n=5+5)
      GoParser           283k ± 0%         283k ± 0%  -0.01%  (p=0.008 n=5+5)
      Reflect            952k ± 0%         951k ± 0%  -0.03%  (p=0.008 n=5+5)
      Tar                188k ± 0%         187k ± 0%  -0.09%  (p=0.008 n=5+5)
      XML                406k ± 0%         406k ± 0%  -0.04%  (p=0.008 n=5+5)
      [Geo mean]         648k              648k       -0.06%
      
      
      This was discovered in the context for the Fannkuch benchmark.
      It shrinks the number of panicindex calls in that function
      from 13 back to 9, their 1.8.1 level.
      
      It shrinks the function text a bit, from 829 to 801 bytes.
      It slows down execution a little, presumably due to alignment (?).
      
      name          old time/op  new time/op  delta
      Fannkuch11-8   2.68s ± 2%   2.74s ± 1%  +2.09%  (p=0.000 n=19+20)
      
      After this CL, 1.8.1 and tip are identical:
      
      name          old time/op  new time/op  delta
      Fannkuch11-8   2.74s ± 2%   2.74s ± 1%   ~     (p=0.301 n=20+20)
      
      Fixes #20332
      
      Change-Id: I2aeacc3e8cf2ac1ff10f36c572a27856f4f8f7c9
      Reviewed-on: https://go-review.googlesource.com/43291
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      e5bb5e39
    • Josh Bleecher Snyder's avatar
      cmd/compile: don't use statictmps for SSA-able composite literals · ee69c217
      Josh Bleecher Snyder authored
      The writebarrier test has to change.
      Now that T23 composite literals are passed to the backend,
      they get SSA'd, so writes to their fields are treated separately,
      so the relevant part of the first write to t23 is now a dead store.
      Preserve the intent of the test by splitting it up into two functions.
      
      Reduces code size a bit:
      
      name        old object-bytes  new object-bytes  delta
      Template           386k ± 0%         386k ± 0%    ~     (all equal)
      Unicode            202k ± 0%         202k ± 0%    ~     (all equal)
      GoTypes           1.16M ± 0%        1.16M ± 0%    ~     (all equal)
      Compiler          3.92M ± 0%        3.91M ± 0%  -0.19%  (p=0.008 n=5+5)
      SSA               7.91M ± 0%        7.91M ± 0%    ~     (all equal)
      Flate              228k ± 0%         228k ± 0%  -0.05%  (p=0.008 n=5+5)
      GoParser           283k ± 0%         283k ± 0%    ~     (all equal)
      Reflect            952k ± 0%         952k ± 0%  -0.06%  (p=0.008 n=5+5)
      Tar                188k ± 0%         188k ± 0%  -0.09%  (p=0.008 n=5+5)
      XML                406k ± 0%         406k ± 0%  -0.02%  (p=0.008 n=5+5)
      [Geo mean]         649k              648k       -0.04%
      
      Fixes #18872
      
      Change-Id: Ifeed0f71f13849732999aa731cc2bf40c0f0e32a
      Reviewed-on: https://go-review.googlesource.com/43154
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      ee69c217
    • Josh Bleecher Snyder's avatar
      cmd/compile: avoid checkwidth of [...] arrays · dccc653a
      Josh Bleecher Snyder authored
      Fixes #20333
      
      Change-Id: I0653cc859076f146d8ea8f5bd55cb22b0b8d987f
      Reviewed-on: https://go-review.googlesource.com/43290
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarJoe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      dccc653a
    • Tom Bergan's avatar
      net/http: for http2, use the priority write scheduler by default · 8f366681
      Tom Bergan authored
      Updates #18318
      
      Change-Id: Ibd4ebc7708abf87eded8da9661378b5777b8a400
      Reviewed-on: https://go-review.googlesource.com/43231
      Run-TryBot: Tom Bergan <tombergan@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8f366681
    • Ben Shi's avatar
      cmd/internal/obj: continue to optimize ARM's constant pool · 6897030f
      Ben Shi authored
      Both Keith's https://go-review.googlesource.com/c/41612/ and
      and Ben's https://go-review.googlesource.com/c/41679/ optimized ARM's
      constant pool. But neither was complete.
      
      First, BIC was forgotten.
      1. "BIC $0xff00ff00, Reg" can be optimized to
         "BIC $0xff000000, Reg
          BIC $0x0000ff00, Reg"
      2. "BIC $0xffff00ff, Reg" can be optimized to
         "AND $0x0000ff00, Reg"
      3. "AND $0xffff00ff, Reg" can be optimized to
         "BIC $0x0000ff00, Reg"
      
      Second, break a non-ARMImmRot to the subtraction of two ARMImmRots was
      left as TODO.
      1. "ADD $0x00fffff0, Reg" can be optimized to
         "ADD $0x01000000, Reg
          SUB $0x00000010, Reg"
      2. "SUB $0x00fffff0, Reg" can be optimized to
         "SUB $0x01000000, Reg
          ADD $0x00000010, Reg"
      
      This patch fixes them and issue #19844.
      
      The go1 benchmark shows improvements.
      
      name                     old time/op    new time/op    delta
      BinaryTree17-4              41.4s ± 1%     41.7s ± 1%  +0.54%  (p=0.000 n=50+49)
      Fannkuch11-4                24.7s ± 1%     25.1s ± 0%  +1.70%  (p=0.000 n=50+49)
      FmtFprintfEmpty-4           853ns ± 1%     852ns ± 1%    ~     (p=0.833 n=50+50)
      FmtFprintfString-4         1.33µs ± 1%    1.33µs ± 1%    ~     (p=0.163 n=50+50)
      FmtFprintfInt-4            1.40µs ± 1%    1.40µs ± 0%    ~     (p=0.293 n=50+35)
      FmtFprintfIntInt-4         2.09µs ± 1%    2.08µs ± 1%  -0.39%  (p=0.000 n=50+49)
      FmtFprintfPrefixedInt-4    2.43µs ± 1%    2.43µs ± 1%    ~     (p=0.552 n=50+50)
      FmtFprintfFloat-4          4.57µs ± 1%    4.42µs ± 1%  -3.18%  (p=0.000 n=50+50)
      FmtManyArgs-4              8.62µs ± 1%    8.52µs ± 0%  -1.08%  (p=0.000 n=50+50)
      GobDecode-4                 101ms ± 1%     101ms ± 2%  +0.45%  (p=0.001 n=49+49)
      GobEncode-4                90.7ms ± 1%    91.1ms ± 2%  +0.51%  (p=0.001 n=50+50)
      Gzip-4                      4.23s ± 1%     4.21s ± 1%  -0.62%  (p=0.000 n=50+50)
      Gunzip-4                    623ms ± 1%     619ms ± 0%  -0.63%  (p=0.000 n=50+42)
      HTTPClientServer-4          721µs ± 5%     683µs ± 3%  -5.25%  (p=0.000 n=50+47)
      JSONEncode-4                251ms ± 1%     253ms ± 1%  +0.54%  (p=0.000 n=49+50)
      JSONDecode-4                941ms ± 1%     944ms ± 1%  +0.30%  (p=0.001 n=49+50)
      Mandelbrot200-4            49.3ms ± 1%    49.3ms ± 0%    ~     (p=0.918 n=50+48)
      GoParse-4                  47.1ms ± 1%    47.2ms ± 1%  +0.18%  (p=0.025 n=50+50)
      RegexpMatchEasy0_32-4      1.23µs ± 1%    1.24µs ± 1%  +0.30%  (p=0.000 n=49+50)
      RegexpMatchEasy0_1K-4      7.74µs ± 7%    7.76µs ± 5%    ~     (p=0.888 n=50+50)
      RegexpMatchEasy1_32-4      1.32µs ± 1%    1.32µs ± 1%  +0.23%  (p=0.003 n=50+50)
      RegexpMatchEasy1_1K-4      10.6µs ± 2%    10.5µs ± 3%  -1.29%  (p=0.000 n=49+50)
      RegexpMatchMedium_32-4     2.19µs ± 1%    2.10µs ± 1%  -3.79%  (p=0.000 n=49+49)
      RegexpMatchMedium_1K-4      544µs ± 0%     545µs ± 0%    ~     (p=0.123 n=41+50)
      RegexpMatchHard_32-4       28.8µs ± 0%    28.8µs ± 1%    ~     (p=0.580 n=46+50)
      RegexpMatchHard_1K-4        863µs ± 1%     865µs ± 1%  +0.31%  (p=0.027 n=47+50)
      Revcomp-4                  82.2ms ± 2%    82.3ms ± 2%    ~     (p=0.894 n=48+49)
      Template-4                  1.06s ± 1%     1.04s ± 1%  -1.18%  (p=0.000 n=50+49)
      TimeParse-4                7.25µs ± 1%    7.35µs ± 0%  +1.48%  (p=0.000 n=50+50)
      TimeFormat-4               13.3µs ± 1%    13.2µs ± 1%  -0.13%  (p=0.007 n=50+50)
      [Geo mean]                  736µs          733µs       -0.37%
      
      name                     old speed      new speed      delta
      GobDecode-4              7.60MB/s ± 1%  7.56MB/s ± 2%  -0.46%  (p=0.001 n=49+49)
      GobEncode-4              8.47MB/s ± 1%  8.42MB/s ± 2%  -0.50%  (p=0.001 n=50+50)
      Gzip-4                   4.58MB/s ± 1%  4.61MB/s ± 1%  +0.59%  (p=0.000 n=50+50)
      Gunzip-4                 31.2MB/s ± 1%  31.4MB/s ± 0%  +0.63%  (p=0.000 n=50+42)
      JSONEncode-4             7.73MB/s ± 1%  7.69MB/s ± 1%  -0.53%  (p=0.000 n=49+50)
      JSONDecode-4             2.06MB/s ± 1%  2.06MB/s ± 1%    ~     (p=0.052 n=44+50)
      GoParse-4                1.23MB/s ± 0%  1.23MB/s ± 2%    ~     (p=0.526 n=26+50)
      RegexpMatchEasy0_32-4    25.9MB/s ± 1%  25.9MB/s ± 1%  -0.30%  (p=0.000 n=49+50)
      RegexpMatchEasy0_1K-4     132MB/s ± 7%   132MB/s ± 6%    ~     (p=0.885 n=50+50)
      RegexpMatchEasy1_32-4    24.2MB/s ± 1%  24.1MB/s ± 1%  -0.22%  (p=0.003 n=50+50)
      RegexpMatchEasy1_1K-4    96.4MB/s ± 2%  97.8MB/s ± 3%  +1.36%  (p=0.000 n=50+50)
      RegexpMatchMedium_32-4    460kB/s ± 0%   476kB/s ± 1%  +3.43%  (p=0.000 n=49+50)
      RegexpMatchMedium_1K-4   1.88MB/s ± 0%  1.88MB/s ± 0%    ~     (all equal)
      RegexpMatchHard_32-4     1.11MB/s ± 0%  1.11MB/s ± 1%  +0.34%  (p=0.000 n=45+50)
      RegexpMatchHard_1K-4     1.19MB/s ± 1%  1.18MB/s ± 1%  -0.34%  (p=0.033 n=50+50)
      Revcomp-4                30.9MB/s ± 2%  30.9MB/s ± 2%    ~     (p=0.894 n=48+49)
      Template-4               1.84MB/s ± 1%  1.86MB/s ± 2%  +1.19%  (p=0.000 n=48+50)
      [Geo mean]               6.63MB/s       6.65MB/s       +0.26%
      
      
      Fixes #19844.
      
      Change-Id: I5ad16cc0b29267bb4579aca3dcc10a0b8ade1aa4
      Reviewed-on: https://go-review.googlesource.com/42430
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      6897030f
    • Daniel Martí's avatar
      reflect: remove dead v.typ assignment · 19b05acd
      Daniel Martí authored
      v is not a pointer receiver, and v.typ isn't used in the lines below.
      The assignment is dead. Remove it.
      
      Keep the comment, as it refers to the whole case block and not just the
      removed line.
      
      Change-Id: Icb2d20c287d9a41bf620ebe5cdec764cd84178a7
      Reviewed-on: https://go-review.googlesource.com/43134
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      19b05acd
  6. 10 May, 2017 13 commits