1. 30 Mar, 2017 15 commits
  2. 29 Mar, 2017 23 commits
    • Elias Naur's avatar
      misc/cgo/testcshared: use the gold linker on android/arm64 · 23f56c18
      Elias Naur authored
      The gold linker is used by default in the Android NDK, except on
      arm64:
      
      https://github.com/android-ndk/ndk/issues/148
      
      The Go linker already forces the use of the gold linker on arm and
      arm64 (CL 22141) for other reasons. However, the test.bash script in
      testcshared doesn't, resulting in linker errors on android/arm64:
      
      warning: liblog.so, needed by ./libgo.so, not found (try using -rpath or
      -rpath-link)
      
      Add -fuse-ld=gold when running testcshared on Android. Fixes the
      android/arm64 builder.
      
      Change-Id: I35ca96f01f136bae72bec56d71b7ca3f344df1ed
      Reviewed-on: https://go-review.googlesource.com/38832
      Run-TryBot: Elias Naur <elias.naur@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      23f56c18
    • Caleb Spare's avatar
      runtime: fix for implementation notes appearing in godoc · 592037f3
      Caleb Spare authored
      Change-Id: I31cfae1e98313b68e3bc8f49079491d2725a662b
      Reviewed-on: https://go-review.googlesource.com/38850Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      592037f3
    • Ilya Tocar's avatar
      math: speed up Log on amd64 · 4f579cc6
      Ilya Tocar authored
      After https://golang.org/cl/31490 we break false
      output dependency for CVTS.. in compiler generated code.
      I've looked through asm code, which uses CVTS..
      and added XOR to the only case where it affected performance.
      
      Log-6                  21.6ns ± 0%  19.9ns ± 0%  -7.87%  (p=0.000 n=10+10)
      
      Change-Id: I25d9b405e3041a3839b40f9f9a52e708034bb347
      Reviewed-on: https://go-review.googlesource.com/38771
      Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      4f579cc6
    • Michael Munday's avatar
      cmd/internal/obj: make morestack cutoff the same on all architectures · 41fd8d64
      Michael Munday authored
      There is always 128 bytes available below the stackguard. Allow functions
      with medium-sized stack frames to use this, potentially allowing them to
      avoid growing the stack.
      
      This change makes all architectures use the same calculation as x86.
      
      Change-Id: I2afb1a7c686ae5a933e50903b31ea4106e4cd0a0
      Reviewed-on: https://go-review.googlesource.com/38734Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      41fd8d64
    • haya14busa's avatar
      regexp: reduce allocations at makeOnePass · fbe67239
      haya14busa authored
      It reduces needless allocations on compiling onepass regex.
      
      Following CL 38750
      
      name                                      old time/op    new time/op    delta
      CompileOnepass/^(?:(?:(?:.(?:$))?))...-4    5.75µs ± 1%    5.51µs ± 2%   -4.25%  (p=0.008 n=5+5)
      CompileOnepass/^abcd$-4                     4.76µs ± 0%    4.52µs ± 1%   -5.06%  (p=0.008 n=5+5)
      CompileOnepass/^(?:(?:a{0,})*?)$-4          5.56µs ± 0%    5.56µs ± 3%     ~     (p=0.524 n=5+5)
      CompileOnepass/^(?:(?:a+)*)$-4              5.09µs ± 0%    5.15µs ± 5%     ~     (p=0.690 n=5+5)
      CompileOnepass/^(?:(?:a|(?:aa)))$-4         6.53µs ± 0%    6.43µs ± 5%     ~     (p=0.151 n=5+5)
      CompileOnepass/^(?:[^\s\S])$-4              4.05µs ± 1%    4.00µs ± 2%     ~     (p=0.095 n=5+5)
      CompileOnepass/^(?:(?:(?:a*)+))$-4          5.47µs ± 0%    5.36µs ± 1%   -1.91%  (p=0.008 n=5+5)
      CompileOnepass/^[a-c]+$-4                   4.13µs ± 1%    4.05µs ± 0%   -2.07%  (p=0.008 n=5+5)
      CompileOnepass/^[a-c]*$-4                   4.59µs ± 2%    4.93µs ± 7%   +7.30%  (p=0.016 n=5+5)
      CompileOnepass/^(?:a*)$-4                   4.67µs ± 1%    4.82µs ± 8%     ~     (p=0.730 n=4+5)
      CompileOnepass/^(?:(?:aa)|a)$-4             6.43µs ± 1%    6.18µs ± 1%   -3.91%  (p=0.008 n=5+5)
      CompileOnepass/^...$-4                      4.71µs ± 0%    4.31µs ± 1%   -8.51%  (p=0.008 n=5+5)
      CompileOnepass/^(?:a|(?:aa))$-4             6.37µs ± 0%    6.17µs ± 0%   -3.23%  (p=0.008 n=5+5)
      CompileOnepass/^a((b))c$-4                  6.85µs ± 1%    6.50µs ± 1%   -5.15%  (p=0.008 n=5+5)
      CompileOnepass/^a.[l-nA-Cg-j]?e$-4          6.99µs ± 1%    6.66µs ± 1%   -4.81%  (p=0.008 n=5+5)
      CompileOnepass/^a((b))$-4                   6.15µs ± 1%    5.87µs ± 0%   -4.57%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:(b)|(c))c$-4            8.62µs ± 1%    8.21µs ± 1%   -4.77%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b|c)$-4                 5.76µs ±42%    4.42µs ± 1%  -23.35%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b?|c)$-4                7.17µs ± 6%    6.86µs ± 0%   -4.39%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b?|c+)$-4               8.08µs ± 2%    7.67µs ± 2%   -4.97%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:bc)+$-4                 5.53µs ± 3%    5.35µs ± 1%   -3.34%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:[bcd])+$-4              5.08µs ± 1%    4.98µs ± 0%   -2.02%  (p=0.008 n=5+5)
      CompileOnepass/^a((?:[bcd])+)$-4            6.49µs ± 1%    6.29µs ± 1%   -3.03%  (p=0.008 n=5+5)
      CompileOnepass/^a(:?b|c)*d$-4               11.8µs ± 1%    11.4µs ± 3%   -3.98%  (p=0.008 n=5+5)
      CompileOnepass/^.bc(d|e)*$-4                8.02µs ± 1%    7.54µs ± 1%   -6.00%  (p=0.008 n=5+5)
      CompileOnepass/^loooooooooooooooooo...-4     228µs ±18%     196µs ± 0%  -14.02%  (p=0.016 n=5+4)
      
      name                                      old alloc/op   new alloc/op   delta
      CompileOnepass/^(?:(?:(?:.(?:$))?))...-4    3.41kB ± 0%    3.38kB ± 0%   -0.94%  (p=0.008 n=5+5)
      CompileOnepass/^abcd$-4                     2.75kB ± 0%    2.74kB ± 0%   -0.29%  (p=0.008 n=5+5)
      CompileOnepass/^(?:(?:a{0,})*?)$-4          3.34kB ± 0%    3.34kB ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:a+)*)$-4              2.95kB ± 0%    2.95kB ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:a|(?:aa)))$-4         3.75kB ± 0%    3.74kB ± 0%   -0.43%  (p=0.008 n=5+5)
      CompileOnepass/^(?:[^\s\S])$-4              2.46kB ± 0%    2.45kB ± 0%   -0.49%  (p=0.008 n=5+5)
      CompileOnepass/^(?:(?:(?:a*)+))$-4          3.13kB ± 0%    3.13kB ± 0%     ~     (all equal)
      CompileOnepass/^[a-c]+$-4                   2.48kB ± 0%    2.48kB ± 0%     ~     (all equal)
      CompileOnepass/^[a-c]*$-4                   2.52kB ± 0%    2.52kB ± 0%     ~     (all equal)
      CompileOnepass/^(?:a*)$-4                   2.63kB ± 0%    2.63kB ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:aa)|a)$-4             3.64kB ± 0%    3.62kB ± 0%   -0.44%  (p=0.008 n=5+5)
      CompileOnepass/^...$-4                      2.91kB ± 0%    2.87kB ± 0%   -1.37%  (p=0.008 n=5+5)
      CompileOnepass/^(?:a|(?:aa))$-4             3.64kB ± 0%    3.62kB ± 0%   -0.44%  (p=0.008 n=5+5)
      CompileOnepass/^a((b))c$-4                  4.39kB ± 0%    4.38kB ± 0%   -0.18%  (p=0.008 n=5+5)
      CompileOnepass/^a.[l-nA-Cg-j]?e$-4          4.32kB ± 0%    4.30kB ± 0%   -0.56%  (p=0.008 n=5+5)
      CompileOnepass/^a((b))$-4                   4.06kB ± 0%    4.05kB ± 0%   -0.39%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:(b)|(c))c$-4            5.31kB ± 0%    5.30kB ± 0%   -0.15%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b|c)$-4                 2.88kB ± 0%    2.87kB ± 0%   -0.28%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b?|c)$-4                4.36kB ± 0%    4.35kB ± 0%   -0.18%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:b?|c+)$-4               4.59kB ± 0%    4.58kB ± 0%   -0.17%  (p=0.008 n=5+5)
      CompileOnepass/^a(?:bc)+$-4                 3.15kB ± 0%    3.15kB ± 0%     ~     (all equal)
      CompileOnepass/^a(?:[bcd])+$-4              2.94kB ± 0%    2.94kB ± 0%     ~     (all equal)
      CompileOnepass/^a((?:[bcd])+)$-4            4.09kB ± 0%    4.08kB ± 0%   -0.20%  (p=0.008 n=5+5)
      CompileOnepass/^a(:?b|c)*d$-4               6.15kB ± 0%    6.10kB ± 0%   -0.78%  (p=0.008 n=5+5)
      CompileOnepass/^.bc(d|e)*$-4                4.47kB ± 0%    4.46kB ± 0%   -0.36%  (p=0.008 n=5+5)
      CompileOnepass/^loooooooooooooooooo...-4     135kB ± 0%     135kB ± 0%     ~     (p=0.810 n=5+5)
      
      name                                      old allocs/op  new allocs/op  delta
      CompileOnepass/^(?:(?:(?:.(?:$))?))...-4      49.0 ± 0%      47.0 ± 0%   -4.08%  (p=0.008 n=5+5)
      CompileOnepass/^abcd$-4                       41.0 ± 0%      41.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:a{0,})*?)$-4            49.0 ± 0%      49.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:a+)*)$-4                44.0 ± 0%      44.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:a|(?:aa)))$-4           54.0 ± 0%      54.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:[^\s\S])$-4                33.0 ± 0%      33.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:(?:a*)+))$-4            46.0 ± 0%      46.0 ± 0%     ~     (all equal)
      CompileOnepass/^[a-c]+$-4                     36.0 ± 0%      36.0 ± 0%     ~     (all equal)
      CompileOnepass/^[a-c]*$-4                     41.0 ± 0%      41.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:a*)$-4                     42.0 ± 0%      42.0 ± 0%     ~     (all equal)
      CompileOnepass/^(?:(?:aa)|a)$-4               53.0 ± 0%      53.0 ± 0%     ~     (all equal)
      CompileOnepass/^...$-4                        43.0 ± 0%      39.0 ± 0%   -9.30%  (p=0.008 n=5+5)
      CompileOnepass/^(?:a|(?:aa))$-4               53.0 ± 0%      53.0 ± 0%     ~     (all equal)
      CompileOnepass/^a((b))c$-4                    53.0 ± 0%      53.0 ± 0%     ~     (all equal)
      CompileOnepass/^a.[l-nA-Cg-j]?e$-4            58.0 ± 0%      56.0 ± 0%   -3.45%  (p=0.008 n=5+5)
      CompileOnepass/^a((b))$-4                     47.0 ± 0%      47.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:(b)|(c))c$-4              65.0 ± 0%      65.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:b|c)$-4                   40.0 ± 0%      40.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:b?|c)$-4                  57.0 ± 0%      57.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:b?|c+)$-4                 63.0 ± 0%      63.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:bc)+$-4                   46.0 ± 0%      46.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(?:[bcd])+$-4                43.0 ± 0%      43.0 ± 0%     ~     (all equal)
      CompileOnepass/^a((?:[bcd])+)$-4              49.0 ± 0%      49.0 ± 0%     ~     (all equal)
      CompileOnepass/^a(:?b|c)*d$-4                  105 ± 0%       101 ± 0%   -3.81%  (p=0.008 n=5+5)
      CompileOnepass/^.bc(d|e)*$-4                  62.0 ± 0%      60.0 ± 0%   -3.23%  (p=0.008 n=5+5)
      CompileOnepass/^loooooooooooooooooo...-4     1.09k ± 0%     1.09k ± 0%     ~     (all equal)
      
      Fixes #19735
      
      Change-Id: Ib90e18e1b06166407b26b2a68b88afbb1f486024
      Reviewed-on: https://go-review.googlesource.com/38751Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      fbe67239
    • Cherry Zhang's avatar
      cmd/compile: improve startRegs calculation · 8a5175df
      Cherry Zhang authored
      In register allocation, we calculate what values are used in
      and after the current block. If a value is used only after a
      function call, since registers are clobbered in call, we don't
      need to mark the value live at the entrance of the block.
      Before this CL it is considered live, and unnecessary copy or
      load may be generated when resolving merge edge.
      
      Fixes #14761.
      
      On AMD64:
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.84s ± 1%     2.81s ± 1%   -1.06%  (p=0.000 n=10+9)
      Fannkuch11-12                3.61s ± 0%     3.55s ± 1%   -1.77%  (p=0.000 n=10+9)
      FmtFprintfEmpty-12          50.4ns ± 4%    50.0ns ± 1%     ~     (p=0.785 n=9+8)
      FmtFprintfString-12         80.0ns ± 3%    78.2ns ± 3%   -2.35%  (p=0.004 n=10+9)
      FmtFprintfInt-12            81.3ns ± 4%    81.8ns ± 2%     ~     (p=0.159 n=10+10)
      FmtFprintfIntInt-12          120ns ± 4%     118ns ± 2%     ~     (p=0.218 n=10+10)
      FmtFprintfPrefixedInt-12     152ns ± 3%     155ns ± 2%   +2.11%  (p=0.026 n=10+10)
      FmtFprintfFloat-12           240ns ± 1%     238ns ± 1%   -0.79%  (p=0.005 n=9+9)
      FmtManyArgs-12               504ns ± 1%     510ns ± 1%   +1.14%  (p=0.000 n=8+9)
      GobDecode-12                7.00ms ± 1%    6.99ms ± 0%     ~     (p=0.497 n=9+10)
      GobEncode-12                5.47ms ± 1%    5.48ms ± 1%     ~     (p=0.218 n=10+10)
      Gzip-12                      258ms ± 2%     256ms ± 1%   -0.96%  (p=0.043 n=10+9)
      Gunzip-12                   38.6ms ± 0%    38.3ms ± 0%   -0.64%  (p=0.000 n=9+8)
      HTTPClientServer-12         90.4µs ± 3%    87.2µs ±11%     ~     (p=0.053 n=9+10)
      JSONEncode-12               15.6ms ± 0%    15.6ms ± 1%     ~     (p=0.077 n=9+9)
      JSONDecode-12               55.1ms ± 1%    54.6ms ± 1%   -0.85%  (p=0.010 n=10+9)
      Mandelbrot200-12            4.49ms ± 0%    4.47ms ± 0%   -0.25%  (p=0.000 n=10+8)
      GoParse-12                  3.38ms ± 0%    3.37ms ± 1%     ~     (p=0.315 n=8+10)
      RegexpMatchEasy0_32-12      82.5ns ± 4%    82.0ns ± 0%     ~     (p=0.164 n=10+8)
      RegexpMatchEasy0_1K-12       203ns ± 1%     202ns ± 1%   -0.85%  (p=0.000 n=9+10)
      RegexpMatchEasy1_32-12      82.3ns ± 1%    81.1ns ± 0%   -1.39%  (p=0.000 n=10+8)
      RegexpMatchEasy1_1K-12       357ns ± 1%     357ns ± 1%     ~     (p=0.697 n=8+9)
      RegexpMatchMedium_32-12      125ns ± 2%     126ns ± 2%     ~     (p=0.197 n=10+10)
      RegexpMatchMedium_1K-12     39.6µs ± 3%    39.6µs ± 1%     ~     (p=0.971 n=10+10)
      RegexpMatchHard_32-12       1.99µs ± 2%    1.99µs ± 4%     ~     (p=0.891 n=10+9)
      RegexpMatchHard_1K-12       60.1µs ± 3%    60.4µs ± 3%     ~     (p=0.684 n=10+10)
      Revcomp-12                   531ms ± 6%     441ms ± 0%  -16.94%  (p=0.000 n=10+9)
      Template-12                 58.9ms ± 1%    58.7ms ± 1%     ~     (p=0.315 n=10+10)
      TimeParse-12                 319ns ± 1%     320ns ± 4%     ~     (p=0.215 n=9+9)
      TimeFormat-12                345ns ± 0%     333ns ± 1%   -3.36%  (p=0.000 n=9+10)
      [Geo mean]                  52.2µs         51.6µs        -1.13%
      
      On ARM64:
      name                     old time/op    new time/op    delta
      BinaryTree17-8              8.53s ± 0%     8.36s ± 0%   -1.89%  (p=0.000 n=10+10)
      Fannkuch11-8                6.15s ± 0%     6.10s ± 0%   -0.67%  (p=0.000 n=10+10)
      FmtFprintfEmpty-8           117ns ± 0%     117ns ± 0%     ~     (all equal)
      FmtFprintfString-8          192ns ± 0%     192ns ± 0%     ~     (all equal)
      FmtFprintfInt-8             198ns ± 0%     198ns ± 0%     ~     (p=0.211 n=10+10)
      FmtFprintfIntInt-8          289ns ± 0%     291ns ± 0%   +0.59%  (p=0.000 n=7+10)
      FmtFprintfPrefixedInt-8     320ns ± 2%     317ns ± 0%     ~     (p=0.431 n=10+8)
      FmtFprintfFloat-8           538ns ± 0%     538ns ± 0%     ~     (all equal)
      FmtManyArgs-8              1.17µs ± 1%    1.18µs ± 1%     ~     (p=0.063 n=10+10)
      GobDecode-8                17.0ms ± 1%    17.2ms ± 1%   +0.83%  (p=0.000 n=10+10)
      GobEncode-8                14.2ms ± 0%    14.1ms ± 1%   -0.78%  (p=0.001 n=9+10)
      Gzip-8                      806ms ± 0%     797ms ± 0%   -1.12%  (p=0.000 n=6+9)
      Gunzip-8                    131ms ± 0%     130ms ± 0%   -0.51%  (p=0.000 n=10+9)
      HTTPClientServer-8          206µs ± 9%     212µs ± 2%     ~     (p=0.829 n=10+8)
      JSONEncode-8               40.1ms ± 0%    40.1ms ± 0%     ~     (p=0.136 n=9+9)
      JSONDecode-8                157ms ± 0%     151ms ± 0%   -3.32%  (p=0.000 n=9+9)
      Mandelbrot200-8            10.1ms ± 0%    10.1ms ± 0%   -0.05%  (p=0.000 n=9+8)
      GoParse-8                  8.43ms ± 0%    8.43ms ± 0%     ~     (p=0.912 n=10+10)
      RegexpMatchEasy0_32-8       228ns ± 1%     227ns ± 0%   -0.26%  (p=0.026 n=10+9)
      RegexpMatchEasy0_1K-8      1.92µs ± 0%    1.63µs ± 0%  -15.18%  (p=0.001 n=7+7)
      RegexpMatchEasy1_32-8       258ns ± 1%     250ns ± 0%   -2.83%  (p=0.000 n=10+10)
      RegexpMatchEasy1_1K-8      2.39µs ± 0%    2.13µs ± 0%  -10.94%  (p=0.000 n=9+9)
      RegexpMatchMedium_32-8      352ns ± 0%     351ns ± 0%   -0.29%  (p=0.004 n=9+10)
      RegexpMatchMedium_1K-8      104µs ± 0%     105µs ± 0%   +0.58%  (p=0.000 n=8+9)
      RegexpMatchHard_32-8       5.84µs ± 0%    5.82µs ± 0%   -0.27%  (p=0.000 n=9+10)
      RegexpMatchHard_1K-8        177µs ± 0%     177µs ± 0%   -0.07%  (p=0.000 n=9+9)
      Revcomp-8                   1.57s ± 1%     1.50s ± 1%   -4.60%  (p=0.000 n=9+10)
      Template-8                  157ms ± 1%     153ms ± 1%   -2.28%  (p=0.000 n=10+9)
      TimeParse-8                 779ns ± 1%     770ns ± 1%   -1.18%  (p=0.013 n=10+10)
      TimeFormat-8                823ns ± 2%     826ns ± 1%     ~     (p=0.324 n=10+9)
      [Geo mean]                  144µs          142µs        -1.45%
      
      Reduce cmd/go text size by 0.5%.
      
      Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117
      Reviewed-on: https://go-review.googlesource.com/38457
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      8a5175df
    • Russ Cox's avatar
      cmd/go: exclude vendored packages from ... matches · fa1d54c2
      Russ Cox authored
      By overwhelming popular demand, exclude vendored packages from ... matches,
      by making ... never match the "vendor" element above a vendored package.
      
      go help packages now reads:
      
          An import path is a pattern if it includes one or more "..." wildcards,
          each of which can match any string, including the empty string and
          strings containing slashes.  Such a pattern expands to all package
          directories found in the GOPATH trees with names matching the
          patterns.
      
          To make common patterns more convenient, there are two special cases.
          First, /... at the end of the pattern can match an empty string,
          so that net/... matches both net and packages in its subdirectories, like net/http.
          Second, any slash-separted pattern element containing a wildcard never
          participates in a match of the "vendor" element in the path of a vendored
          package, so that ./... does not match packages in subdirectories of
          ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do.
          Note, however, that a directory named vendor that itself contains code
          is not a vendored package: cmd/vendor would be a command named vendor,
          and the pattern cmd/... matches it.
      
      Fixes #19090.
      
      Change-Id: I985bf9571100da316c19fbfd19bb1e534a3c9e5f
      Reviewed-on: https://go-review.googlesource.com/38745Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      fa1d54c2
    • Keith Randall's avatar
      Revert "cmd/compile: automatically handle commuting ops in rewrite rules" · 68da265c
      Keith Randall authored
      This reverts commit 041ecb69.
      
      Reason for revert: Not working on S390x and some 386 archs.
      I have a guess why the S390x is failing.  No clue on the 386 yet.
      Revert until I can figure it out.
      
      Change-Id: I64f1ce78fa6d1037ebe7ee2a8a8107cb4c1db70c
      Reviewed-on: https://go-review.googlesource.com/38790Reviewed-by: default avatarKeith Randall <khr@golang.org>
      68da265c
    • Russ Cox's avatar
      cmd/go: make pattern matching tests less repetitive · 8295dbda
      Russ Cox authored
      Change-Id: I25db1d637dd461cec67ba70659d523b46895c113
      Reviewed-on: https://go-review.googlesource.com/38744Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      8295dbda
    • Russ Cox's avatar
      cmd/go: fix bug in test of go get ./path needing to download path · f0a3018b
      Russ Cox authored
      rsc.io/toolstash is gone; use rsc.io/pprof_mac_fix.
      
      This fixes a bug in the test. It turns out the code being tested here
      is also broken, so the test still doesn't pass after this CL (filed #19769).
      
      Change-Id: Ieb725c321d7fab600708e133ae28f531e55521ad
      Reviewed-on: https://go-review.googlesource.com/38743Reviewed-by: default avatarAlan Donovan <adonovan@google.com>
      f0a3018b
    • David Chase's avatar
      cmd/compile: added special case for reflect header fields to esc · 24e94766
      David Chase authored
      The uintptr-typed Data field in reflect.SliceHeader and
      reflect.StringHeader needs special treatment because it is
      really a pointer.  Add the special treatment in walk for
      bug #19168 to escape analysis.
      
      Includes extra debugging that was helpful.
      
      Fixes #19743.
      
      Change-Id: I6dab5002f0d436c3b2a7cdc0156e4fc48a43d6fe
      Reviewed-on: https://go-review.googlesource.com/38738
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      24e94766
    • David Lazar's avatar
      cmd/compile: fix names of inlined methods from other packages · 83843b16
      David Lazar authored
      Previously, an inlined call to wg.Done() in package main would have the
      following incorrect symbol name:
      
          main.(*sync.WaitGroup).Done
      
      This change modifies methodname to return the correct symbol name:
      
          sync.(*WaitGroup).Done
      
      This fix was suggested by @mdempsky.
      
      Fixes #19467.
      
      Change-Id: I0117838679ac5353789299c618ff8c326712d94d
      Reviewed-on: https://go-review.googlesource.com/37866Reviewed-by: default avatarAustin Clements <austin@google.com>
      83843b16
    • David Lazar's avatar
      runtime: include inlined calls in result of CallersFrames · 7bf0adc6
      David Lazar authored
      Change-Id: If1a3396175f2afa607d56efd1444181334a9ae3e
      Reviewed-on: https://go-review.googlesource.com/37862Reviewed-by: default avatarAustin Clements <austin@google.com>
      7bf0adc6
    • David Lazar's avatar
      runtime: handle inlined calls in runtime.Callers · ee97216a
      David Lazar authored
      The `skip` argument passed to runtime.Caller and runtime.Callers should
      be interpreted as the number of logical calls to skip (rather than the
      number of physical stack frames to skip). This changes runtime.Callers
      to skip inlined calls in addition to physical stack frames.
      
      The result value of runtime.Callers is a slice of program counters
      ([]uintptr) representing physical stack frames. If the `skip` parameter
      to runtime.Callers skips part-way into a physical frame, there is no
      convenient way to encode that in the resulting slice. To avoid changing
      the API in an incompatible way, our solution is to store the number of
      skipped logical calls of the first frame in the _second_ uintptr
      returned by runtime.Callers. Since this number is a small integer, we
      encode it as a valid PC value into a small symbol called:
      
          runtime.skipPleaseUseCallersFrames
      
      For example, if f() calls g(), g() calls `runtime.Callers(2, pcs)`, and
      g() is inlined into f, then the frame for f will be partially skipped,
      resulting in the following slice:
      
          pcs = []uintptr{pc_in_f, runtime.skipPleaseUseCallersFrames+1, ...}
      
      We store the skip PC in pcs[1] instead of pcs[0] so that `pcs[i:]` will
      truncate the captured stack trace rather than grow it for all i.
      
      Updates #19348.
      
      Change-Id: I1c56f89ac48c29e6f52a5d085567c6d77d499cf1
      Reviewed-on: https://go-review.googlesource.com/37854
      Run-TryBot: David Lazar <lazard@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      ee97216a
    • David Lazar's avatar
      test: allow flags in run action · f3f5b10e
      David Lazar authored
      Previously, we could not run tests with -l=4 on NaCl since the buildrun
      action is not supported on NaCl. This lets us run tests with build flags
      on NaCl.
      
      Change-Id: I103370c7b823b4ff46f47df97e802da0dc2bc7c3
      Reviewed-on: https://go-review.googlesource.com/38170
      Run-TryBot: David Lazar <lazard@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      f3f5b10e
    • Russ Cox's avatar
      cmd/go: build test binaries with -s in addition to -w · 94c95d3e
      Russ Cox authored
      Fixes #19753.
      
      Change-Id: Ib20a69b1d0bcc42aa9e924918bcb578d6a560a31
      Reviewed-on: https://go-review.googlesource.com/38742
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      94c95d3e
    • Brad Fitzpatrick's avatar
      net, net/http: adjust time-in-past constant even earlier · 6983b9a5
      Brad Fitzpatrick authored
      The aLongTimeAgo time value in net and net/http is used to cancel
      in-flight read and writes. It was set to time.Unix(233431200, 0)
      which seemed like far enough in the past.
      
      But Raspberry Pis, lacking a real time clock, had to spoil the fun and
      boot in 1970 at the Unix epoch time, breaking assumptions in net and
      net/http.
      
      So change aLongTimeAgo to time.Unix(1, 0), which seems like the
      earliest safe value. I don't trust subsecond values on all operating
      systems, and I don't trust the Unix zero time. The Raspberry Pis do
      advance their clock at least. And the reported problem was that Hijack
      on a ResponseWriter hung forever, waiting for the connection read
      operation to finish. So now, even if kernel + userspace boots in under
      a second (unlikely), the Hijack will just have to wait for up to a
      second.
      
      Fixes #19747
      
      Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a
      Reviewed-on: https://go-review.googlesource.com/38785
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      6983b9a5
    • Keith Randall's avatar
      cmd/compile: automatically handle commuting ops in rewrite rules · 041ecb69
      Keith Randall authored
      We have lots of rewrite rules that vary only in the fact that
      we have 2 versions for the 2 different orderings of various
      commuting ops. For example:
      
      (ADDL x (MOVLconst [c])) -> (ADDLconst [c] x)
      (ADDL (MOVLconst [c]) x) -> (ADDLconst [c] x)
      
      It can get unwieldly quickly, especially when there is more than
      one commuting op in a rule.
      
      Our existing "fix" for this problem is to have rules that
      canonicalize the operations first. For example:
      
      (Eq64 x (Const64 <t> [c])) && x.Op != OpConst64 -> (Eq64 (Const64 <t> [c]) x)
      
      Subsequent rules can then assume if there is a constant arg to Eq64,
      it will be the first one. This fix kinda works, but it is fragile and
      only works when we remember to include the required extra rules.
      
      The fundamental problem is that the rule matcher doesn't
      know anything about commuting ops. This CL fixes that fact.
      
      We already have information about which ops commute. (The register
      allocator takes advantage of commutivity.)  The rule generator now
      automatically generates multiple rules for a single source rule when
      there are commutative ops in the rule. We can now drop all of our
      almost-duplicate source-level rules and the canonicalization rules.
      
      I have some CLs in progress that will be a lot less verbose when
      the rule generator handles commutivity for me.
      
      I had to reorganize the load-combining rules a bit. The 8-way OR rules
      generated 128 different reorderings, which was causing the generator
      to put too much code in the rewrite*.go files (the big ones were going
      from 25K lines to 132K lines). Instead I reorganized the rules to
      combine pairs of loads at a time. The generated rule files are now
      actually a bit (5%) smaller.
      [Note to reviewers: check these carefully. Most of the other rule
      changes are trivial.]
      
      Make.bash times are ~unchanged.
      
      Compiler benchmarks are not observably different. Probably because
      we don't spend much compiler time in rule matching anyway.
      
      I've also done a pass over all of our ops adding commutative markings
      for ops which hadn't had them previously.
      
      Fixes #18292
      
      Change-Id: I999b1307272e91965b66754576019dedcbe7527a
      Reviewed-on: https://go-review.googlesource.com/38666
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      041ecb69
    • Austin Clements's avatar
      reflect: fix out-of-bounds pointers calling no-result method · 627798db
      Austin Clements authored
      reflect.callReflect heap-allocates a stack frame and then constructs
      pointers to the arguments and result areas of that frame. However, if
      there are no results, the results pointer will point past the end of
      the frame allocation. If there are also no arguments, the arguments
      pointer will also point past the end of the frame allocation. If the
      GC observes either these pointers, it may panic.
      
      Fix this by not constructing these pointers if these areas of the
      frame are empty.
      
      This adds a test of calling no-argument/no-result methods via reflect,
      since nothing in std did this before. However, it's quite difficult to
      demonstrate the actual failure because it depends on both exact
      allocation patterns and on GC scanning the goroutine's stack while
      inside one of the typedmemmovepartial calls.
      
      I also audited other uses of typedmemmovepartial and
      memclrNoHeapPointers in reflect, since these are the most susceptible
      to this. These appear to be the only two cases that can construct
      out-of-bounds arguments to these functions.
      
      Fixes #19724.
      
      Change-Id: I4b83c596b5625dc4ad0567b1e281bad4faef972b
      Reviewed-on: https://go-review.googlesource.com/38736
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      627798db
    • Rick Hudson's avatar
      runtime: redo insert/remove of large spans · 6e9ec141
      Rick Hudson authored
      Currently for spans with up to 1 MBytes (128 pages) we
      maintain an array indexed by the number of pages in the
      span. This is efficient both in terms of space as well
      as time to insert or remove a span of a particular size.
      
      Unfortunately for spans larger than 1 MByte we currently
      place them on a separate linked list. This results in
      O(n) behavior. Now that we are seeing heaps approaching
      100 GBytes n is large enough to be noticed in real programs.
      
      This change replaces the linked list now used with a balanced
      binary tree structure called a treap. A treap is a
      probabilistically balanced tree offering O(logN) behavior for
      inserting and removing spans.
      
      To verify that this approach will work we start with noting
      that only spans with sizes > 1MByte will be put into the treap.
      This means that to support 1 TByte a treap will need at most
      1 million nodes and can ideally be held in a treap with a
      depth of 20. Experiments with adding and removing randomly
      sized spans from the treap seem to result in treaps with
      depths of about twice the ideal or 40. A petabyte would
      require a tree of only twice again that depth again so this
      algorithm should last well into the future.
      
      Fixes #19393
      
      Go1 benchmarks indicate this is basically an overall wash.
      Tue Mar 28 21:29:21 EDT 2017
      name                     old time/op    new time/op    delta
      BinaryTree17-4              2.42s ± 1%     2.42s ± 1%    ~     (p=0.980 n=21+21)
      Fannkuch11-4                3.00s ± 1%     3.18s ± 4%  +6.10%  (p=0.000 n=22+24)
      FmtFprintfEmpty-4          40.5ns ± 1%    40.3ns ± 3%    ~     (p=0.692 n=22+25)
      FmtFprintfString-4         65.9ns ± 3%    64.6ns ± 1%  -1.98%  (p=0.000 n=24+23)
      FmtFprintfInt-4            69.6ns ± 1%    68.0ns ± 7%  -2.30%  (p=0.001 n=21+22)
      FmtFprintfIntInt-4          102ns ± 2%      99ns ± 1%  -3.07%  (p=0.000 n=23+23)
      FmtFprintfPrefixedInt-4     126ns ± 0%     125ns ± 0%  -0.79%  (p=0.000 n=19+17)
      FmtFprintfFloat-4           206ns ± 2%     205ns ± 1%    ~     (p=0.671 n=23+21)
      FmtManyArgs-4               441ns ± 1%     445ns ± 1%  +0.88%  (p=0.000 n=22+23)
      GobDecode-4                5.73ms ± 1%    5.86ms ± 1%  +2.37%  (p=0.000 n=23+22)
      GobEncode-4                4.51ms ± 1%    4.89ms ± 1%  +8.32%  (p=0.000 n=22+22)
      Gzip-4                      197ms ± 0%     202ms ± 1%  +2.75%  (p=0.000 n=23+24)
      Gunzip-4                   32.9ms ± 8%    32.7ms ± 2%    ~     (p=0.466 n=23+24)
      HTTPClientServer-4         57.3µs ± 1%    56.7µs ± 1%  -0.94%  (p=0.000 n=21+22)
      JSONEncode-4               13.8ms ± 1%    13.9ms ± 2%  +1.14%  (p=0.000 n=22+23)
      JSONDecode-4               47.4ms ± 1%    48.1ms ± 1%  +1.49%  (p=0.000 n=23+23)
      Mandelbrot200-4            3.92ms ± 0%    3.92ms ± 1%  +0.21%  (p=0.000 n=22+22)
      GoParse-4                  2.89ms ± 1%    2.87ms ± 1%  -0.68%  (p=0.000 n=21+22)
      RegexpMatchEasy0_32-4      73.6ns ± 1%    72.0ns ± 2%  -2.15%  (p=0.000 n=21+22)
      RegexpMatchEasy0_1K-4       173ns ± 1%     173ns ± 1%    ~     (p=0.847 n=22+24)
      RegexpMatchEasy1_32-4      71.9ns ± 1%    69.8ns ± 1%  -2.99%  (p=0.000 n=23+20)
      RegexpMatchEasy1_1K-4       314ns ± 1%     308ns ± 1%  -1.91%  (p=0.000 n=22+23)
      RegexpMatchMedium_32-4      106ns ± 0%     105ns ± 1%  -0.58%  (p=0.000 n=19+21)
      RegexpMatchMedium_1K-4     34.3µs ± 1%    34.3µs ± 1%    ~     (p=0.871 n=23+22)
      RegexpMatchHard_32-4       1.67µs ± 1%    1.67µs ± 7%    ~     (p=0.224 n=22+23)
      RegexpMatchHard_1K-4       51.5µs ± 1%    50.4µs ± 1%  -1.99%  (p=0.000 n=22+23)
      Revcomp-4                   383ms ± 1%     415ms ± 0%  +8.51%  (p=0.000 n=22+22)
      Template-4                 51.5ms ± 1%    51.5ms ± 1%    ~     (p=0.555 n=20+23)
      TimeParse-4                 279ns ± 2%     277ns ± 1%  -0.95%  (p=0.000 n=24+22)
      TimeFormat-4                294ns ± 1%     296ns ± 1%  +0.58%  (p=0.003 n=24+23)
      [Geo mean]                 43.7µs         43.8µs       +0.32%
      
      name                     old speed      new speed      delta
      GobDecode-4               134MB/s ± 1%   131MB/s ± 1%  -2.32%  (p=0.000 n=23+22)
      GobEncode-4               170MB/s ± 1%   157MB/s ± 1%  -7.68%  (p=0.000 n=22+22)
      Gzip-4                   98.7MB/s ± 0%  96.1MB/s ± 1%  -2.68%  (p=0.000 n=23+24)
      Gunzip-4                  590MB/s ± 7%   593MB/s ± 2%    ~     (p=0.466 n=23+24)
      JSONEncode-4              141MB/s ± 1%   139MB/s ± 2%  -1.13%  (p=0.000 n=22+23)
      JSONDecode-4             40.9MB/s ± 1%  40.3MB/s ± 0%  -1.47%  (p=0.000 n=23+23)
      GoParse-4                20.1MB/s ± 1%  20.2MB/s ± 1%  +0.69%  (p=0.000 n=21+22)
      RegexpMatchEasy0_32-4     435MB/s ± 1%   444MB/s ± 2%  +2.21%  (p=0.000 n=21+22)
      RegexpMatchEasy0_1K-4    5.89GB/s ± 1%  5.89GB/s ± 1%    ~     (p=0.439 n=22+24)
      RegexpMatchEasy1_32-4     445MB/s ± 1%   459MB/s ± 1%  +3.06%  (p=0.000 n=23+20)
      RegexpMatchEasy1_1K-4    3.26GB/s ± 1%  3.32GB/s ± 1%  +1.97%  (p=0.000 n=22+23)
      RegexpMatchMedium_32-4   9.40MB/s ± 1%  9.44MB/s ± 1%  +0.43%  (p=0.000 n=23+21)
      RegexpMatchMedium_1K-4   29.8MB/s ± 1%  29.8MB/s ± 1%    ~     (p=0.826 n=23+22)
      RegexpMatchHard_32-4     19.1MB/s ± 1%  19.1MB/s ± 7%    ~     (p=0.233 n=22+23)
      RegexpMatchHard_1K-4     19.9MB/s ± 1%  20.3MB/s ± 1%  +2.03%  (p=0.000 n=22+23)
      Revcomp-4                 664MB/s ± 1%   612MB/s ± 0%  -7.85%  (p=0.000 n=22+22)
      Template-4               37.6MB/s ± 1%  37.7MB/s ± 1%    ~     (p=0.558 n=20+23)
      [Geo mean]                134MB/s        133MB/s       -0.76%
      Tue Mar 28 22:16:54 EDT 2017
      
      Change-Id: I4a4f5c2b53d3fb85ef76c98522d3ed5cf8ae5b7e
      Reviewed-on: https://go-review.googlesource.com/38732Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      6e9ec141
    • haya14busa's avatar
      cmd/go: add -json flag to go env · 846f9254
      haya14busa authored
      "go env" prints Go environment information as a shell script format by
      default but it's difficult for some tools (e.g. editor packages) to
      interpret it.
      
      The -json flag prints the environment in JSON format which
      can be easily interpreted by a lot of tools.
      
      $ go env -json
      {
              "CC": "gcc",
              "CGO_CFLAGS": "-g -O2",
              "CGO_CPPFLAGS": "",
              "CGO_CXXFLAGS": "-g -O2",
              "CGO_ENABLED": "1",
              "CGO_FFLAGS": "-g -O2",
              "CGO_LDFLAGS": "-g -O2",
              "CXX": "g++",
              "GCCGO": "gccgo",
              "GOARCH": "amd64",
              "GOBIN": "/home/haya14busa/go/bin",
              "GOEXE": "",
              "GOGCCFLAGS": "-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build498013955=/tmp/go-build -gno-record-gcc-switches",
              "GOHOSTARCH": "amd64",
              "GOHOSTOS": "linux",
              "GOOS": "linux",
              "GOPATH": "/home/haya14busa",
              "GORACE": "",
              "GOROOT": "/home/haya14busa/src/go.googlesource.com/go",
              "GOTOOLDIR": "/home/haya14busa/src/go.googlesource.com/go/pkg/tool/linux_amd64",
              "PKG_CONFIG": "pkg-config"
      }
      
      Also, it supports arguments with -json flag.
      
      $ go env -json GOROOT GOPATH GOBIN
      {
              "GOBIN": "/home/haya14busa/go/bin",
              "GOPATH": "/home/haya14busa",
              "GOROOT": "/home/haya14busa/src/go.googlesource.com/go"
      }
      
      Fixes #12567
      
      Change-Id: I75db3780f14a8ab8c7fa58cc3c9cc488ef7b66a1
      Reviewed-on: https://go-review.googlesource.com/38757Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      846f9254
    • Dave Cheney's avatar
      cmd/compile/internal/gc: remove unused state.placeholder field · 9f232c17
      Dave Cheney authored
      gc.state.placeholder was added in 5a6e511c but never used.
      
      Change-Id: I5a621507279d5bb1f3991b7a412d9a63039c464e
      Reviewed-on: https://go-review.googlesource.com/38755Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9f232c17
    • Dave Cheney's avatar
      cmd/internal/obj/x86: clean up byteswapreg · 54af1870
      Dave Cheney authored
      Make byteswapreg more Go like.
      
      Change-Id: Ibdf3603cae9cad2b3465b4c224a28a4c4c745c2e
      Reviewed-on: https://go-review.googlesource.com/38615
      Run-TryBot: Dave Cheney <dave@cheney.net>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      54af1870
  3. 28 Mar, 2017 2 commits