1. 28 Aug, 2017 11 commits
    • David du Colombier's avatar
      cmd/compile: don't use MOVOstore for move on plan9/amd64 · adbfdfe3
      David du Colombier authored
      The SSA compiler currently generates MOVOstore instructions
      to optimize 16 bytes moves on AMD64 architecture.
      
      However, we can't use the MOVOstore instruction on Plan 9,
      because floating point operations are not allowed in the
      note handler.
      
      We rely on the useSSE flag to disable the use of the
      MOVOstore instruction on Plan 9 and replace it by two
      MOVQstore instructions.
      
      Fixes #21625
      
      Change-Id: Idfefcceadccafe1752b059b5fe113ce566c0e71c
      Reviewed-on: https://go-review.googlesource.com/59171
      Run-TryBot: David du Colombier <0intro@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIlya Tocar <ilya.tocar@intel.com>
      adbfdfe3
    • Artyom Pervukhin's avatar
      net/http: mention RegisterOnShutdown in Server.Shutdown docs · c875cea7
      Artyom Pervukhin authored
      Closes #21637
      
      Change-Id: Icc3528572ea2a25e62757cc8fbbb9c3fa96a78b2
      Reviewed-on: https://go-review.googlesource.com/59350Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
      c875cea7
    • Ben Shi's avatar
      cmd/compile: optimize ARM with more efficient MOVB/MOVBU/MOVH/MOVHU · a2f22a68
      Ben Shi authored
      Like the indexed MOVW (MOVWloadidx/MOVWstoreidx) used in current
      ARM backend, the indexed MOVB/MOVBU/MOVH/MOVHU can also be used to
      generate further optimized ARM code.
      
      My patch implements this optimization. Here are some contrast test
      results against the original go compiler.
      
      1. The total size of all .a files in pkg/ shrinks by 0.03%.
      
      2. The compilecmp benchmark shows a little decline.
      name        old time/op       new time/op       delta
      Template          2.35s ± 1%        2.37s ± 3%  +0.94%  (p=0.006 n=19+19)
      Unicode           1.33s ± 3%        1.33s ± 2%    ~     (p=0.158 n=20+18)
      GoTypes           7.86s ± 2%        7.84s ± 1%    ~     (p=0.284 n=19+18)
      Compiler          37.5s ± 1%        37.7s ± 2%    ~     (p=0.101 n=20+19)
      SSA               83.4s ± 2%        83.6s ± 2%    ~     (p=0.231 n=20+20)
      Flate             1.46s ± 2%        1.45s ± 1%    ~     (p=0.097 n=20+17)
      GoParser          1.86s ± 2%        1.86s ± 4%    ~     (p=0.738 n=20+20)
      Reflect           5.10s ± 1%        5.11s ± 1%    ~     (p=0.290 n=20+18)
      Tar               1.78s ± 2%        1.77s ± 2%    ~     (p=0.166 n=19+20)
      XML               2.61s ± 2%        2.61s ± 2%    ~     (p=0.665 n=19+19)
      [Geo mean]        4.67s             4.68s       +0.16%
      
      name        old user-time/op  new user-time/op  delta
      Template          2.79s ± 3%        2.80s ± 2%    ~     (p=0.662 n=20+20)
      Unicode           1.62s ± 3%        1.64s ± 4%    ~     (p=0.252 n=20+20)
      GoTypes           9.58s ± 2%        9.62s ± 2%    ~     (p=0.250 n=20+20)
      Compiler          46.2s ± 1%        46.2s ± 1%    ~     (p=0.602 n=20+19)
      SSA                108s ± 1%         108s ± 2%    ~     (p=0.242 n=18+20)
      Flate             1.69s ± 3%        1.69s ± 4%    ~     (p=0.470 n=20+20)
      GoParser          2.16s ± 3%        2.20s ± 4%  +1.70%  (p=0.005 n=19+20)
      Reflect           6.02s ± 2%        6.02s ± 2%    ~     (p=0.700 n=20+17)
      Tar               2.11s ± 2%        2.11s ± 3%    ~     (p=0.480 n=18+20)
      XML               3.07s ± 2%        3.11s ± 4%  +1.50%  (p=0.043 n=20+20)
      [Geo mean]        5.61s             5.64s       +0.55%
      
      name        old text-bytes    new text-bytes    delta
      HelloSize         586kB ± 0%        586kB ± 0%    ~     (all equal)
      
      name        old data-bytes    new data-bytes    delta
      HelloSize        5.46kB ± 0%       5.46kB ± 0%    ~     (all equal)
      
      name        old bss-bytes     new bss-bytes     delta
      HelloSize        72.9kB ± 0%       72.9kB ± 0%    ~     (all equal)
      
      name        old exe-bytes     new exe-bytes     delta
      HelloSize        1.03MB ± 0%       1.03MB ± 0%    ~     (all equal)
      
      3. The go1 benchmark shows improvement totally, and even more than 10%
      improvement in the test case Revcomp. 
      name                     old time/op    new time/op    delta
      BinaryTree17-4              42.0s ± 1%     41.5s ± 1%   -1.32%  (p=0.000 n=39+40)
      Fannkuch11-4                24.1s ± 1%     23.6s ± 0%   -2.38%  (p=0.000 n=40+40)
      FmtFprintfEmpty-4           843ns ± 0%     839ns ± 1%   -0.46%  (p=0.000 n=33+40)
      FmtFprintfString-4         1.44µs ± 1%    1.37µs ± 1%   -5.48%  (p=0.000 n=40+35)
      FmtFprintfInt-4            1.44µs ± 1%    1.41µs ± 2%   -1.50%  (p=0.000 n=40+40)
      FmtFprintfIntInt-4         2.07µs ± 1%    2.06µs ± 0%   -0.78%  (p=0.000 n=40+40)
      FmtFprintfPrefixedInt-4    2.50µs ± 1%    2.33µs ± 1%   -6.85%  (p=0.000 n=40+40)
      FmtFprintfFloat-4          4.36µs ± 1%    4.34µs ± 0%   -0.39%  (p=0.017 n=40+40)
      FmtManyArgs-4              8.11µs ± 0%    8.00µs ± 0%   -1.37%  (p=0.000 n=40+40)
      GobDecode-4                 105ms ± 2%     103ms ± 2%   -2.17%  (p=0.000 n=39+39)
      GobEncode-4                90.1ms ± 2%    88.6ms ± 1%   -1.67%  (p=0.000 n=40+39)
      Gzip-4                      4.18s ± 1%     4.09s ± 1%   -2.03%  (p=0.000 n=40+40)
      Gunzip-4                    608ms ± 1%     603ms ± 1%   -0.86%  (p=0.000 n=40+34)
      HTTPClientServer-4          674µs ± 3%     661µs ± 2%   -1.82%  (p=0.000 n=40+39)
      JSONEncode-4                256ms ± 1%     243ms ± 0%   -5.11%  (p=0.000 n=39+31)
      JSONDecode-4                915ms ± 1%     904ms ± 1%   -1.18%  (p=0.000 n=40+36)
      Mandelbrot200-4            49.2ms ± 0%    49.3ms ± 0%     ~     (p=0.254 n=34+40)
      GoParse-4                  46.9ms ± 2%    46.9ms ± 1%     ~     (p=0.737 n=40+39)
      RegexpMatchEasy0_32-4      1.28µs ± 1%    1.27µs ± 1%   -0.71%  (p=0.000 n=40+40)
      RegexpMatchEasy0_1K-4      7.86µs ± 4%    7.67µs ± 4%   -2.46%  (p=0.000 n=38+40)
      RegexpMatchEasy1_32-4      1.28µs ± 1%    1.28µs ± 1%   -0.54%  (p=0.000 n=40+40)
      RegexpMatchEasy1_1K-4      10.4µs ± 2%    10.3µs ± 2%   -0.88%  (p=0.003 n=40+39)
      RegexpMatchMedium_32-4     2.05µs ± 0%    2.04µs ± 0%   -0.34%  (p=0.000 n=40+33)
      RegexpMatchMedium_1K-4      541µs ± 1%     535µs ± 1%   -1.02%  (p=0.000 n=40+38)
      RegexpMatchHard_32-4       29.3µs ± 1%    29.1µs ± 1%   -0.51%  (p=0.000 n=40+40)
      RegexpMatchHard_1K-4        881µs ± 1%     871µs ± 1%   -1.15%  (p=0.000 n=40+40)
      Revcomp-4                  81.7ms ± 2%    67.5ms ± 2%  -17.37%  (p=0.000 n=39+39)
      Template-4                  1.05s ± 1%     1.08s ± 2%   +3.67%  (p=0.000 n=40+40)
      TimeParse-4                7.24µs ± 1%    7.09µs ± 1%   -2.13%  (p=0.000 n=40+40)
      TimeFormat-4               13.2µs ± 1%    13.1µs ± 0%   -0.31%  (p=0.007 n=40+31)
      [Geo mean]                  733µs          718µs        -2.03%
      
      name                     old speed      new speed      delta
      GobDecode-4              7.28MB/s ± 2%  7.44MB/s ± 2%   +2.23%  (p=0.000 n=39+39)
      GobEncode-4              8.52MB/s ± 2%  8.67MB/s ± 1%   +1.70%  (p=0.000 n=40+39)
      Gzip-4                   4.65MB/s ± 1%  4.74MB/s ± 1%   +1.94%  (p=0.000 n=37+40)
      Gunzip-4                 31.9MB/s ± 1%  32.2MB/s ± 1%   +0.90%  (p=0.000 n=40+36)
      JSONEncode-4             7.57MB/s ± 1%  7.98MB/s ± 0%   +5.41%  (p=0.000 n=40+31)
      JSONDecode-4             2.12MB/s ± 1%  2.15MB/s ± 1%   +1.23%  (p=0.000 n=40+40)
      GoParse-4                1.23MB/s ± 1%  1.23MB/s ± 1%     ~     (p=0.769 n=39+40)
      RegexpMatchEasy0_32-4    25.0MB/s ± 1%  25.2MB/s ± 1%   +0.71%  (p=0.000 n=40+40)
      RegexpMatchEasy0_1K-4     130MB/s ± 5%   134MB/s ± 4%   +2.53%  (p=0.000 n=38+40)
      RegexpMatchEasy1_32-4    24.9MB/s ± 1%  25.1MB/s ± 1%   +0.55%  (p=0.000 n=40+40)
      RegexpMatchEasy1_1K-4    98.5MB/s ± 2%  99.4MB/s ± 2%   +0.88%  (p=0.003 n=40+39)
      RegexpMatchMedium_32-4    490kB/s ± 0%   490kB/s ± 0%     ~     (all equal)
      RegexpMatchMedium_1K-4   1.89MB/s ± 1%  1.91MB/s ± 1%   +1.02%  (p=0.000 n=40+38)
      RegexpMatchHard_32-4     1.10MB/s ± 1%  1.10MB/s ± 0%   +0.41%  (p=0.000 n=40+33)
      RegexpMatchHard_1K-4     1.16MB/s ± 1%  1.17MB/s ± 1%   +1.21%  (p=0.000 n=40+40)
      Revcomp-4                31.1MB/s ± 2%  37.6MB/s ± 2%  +21.03%  (p=0.000 n=39+39)
      Template-4               1.86MB/s ± 1%  1.79MB/s ± 1%   -3.51%  (p=0.000 n=40+38)
      [Geo mean]               6.66MB/s       6.80MB/s        +2.13%
      
      fixes #21492
      
      Change-Id: Ia26e7ca393f0a5f31de240e8ff9a220453ca7e0d
      Reviewed-on: https://go-review.googlesource.com/58450Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      a2f22a68
    • Matej Baćo's avatar
      regexp: examples for Regexp.Expand and Regexp.ExpandString functions · 1fe1512f
      Matej Baćo authored
      Current documentation lacks simple examples for functions Regexp.Expand
      and Regexp.ExpandString whose usage is unclear from description alone.
      This commit adds examples that demonstrate usage in practical way.
      
      Fixes #21649
      
      Change-Id: I7b2c06c8ab747f69a6578f0595bf0f3c742ac479
      Reviewed-on: https://go-review.googlesource.com/59470Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      1fe1512f
    • Wei Xiao's avatar
      cmd/internal/objfile: add arm64 disassembler support · c195deb4
      Wei Xiao authored
      Fixes #19157
      
      Change-Id: Ieea286e8dc03929c3645f3113c33df569f8e26f3
      Reviewed-on: https://go-review.googlesource.com/58930Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      c195deb4
    • Daniel Martí's avatar
      all: remove some unused result params · 5d39af9d
      Daniel Martí authored
      Most of these are return values that were part of a receiving parameter,
      so they're still accessible.
      
      A few others are not, but those have never had a use.
      
      Found with github.com/mvdan/unparam, after Kevin Burke's suggestion that
      the tool should also warn about unused result parameters.
      
      Change-Id: Id8b5ed89912a99db22027703a88bd94d0b292b8b
      Reviewed-on: https://go-review.googlesource.com/55910
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      5d39af9d
    • Hiroshi Ioka's avatar
      cmd/link: refactor *reloc · 0c4d035c
      Hiroshi Ioka authored
      * use bool instead of int if it's adequate.
      * remove blank lines.
      
      Change-Id: Ic4a5644a33ed9fc7ce388ef8ba15f1732446fcfc
      Reviewed-on: https://go-review.googlesource.com/59375
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      0c4d035c
    • Josh Bleecher Snyder's avatar
      cmd/compile: use raceX instead of raceXrange for types without subcomponents · 53c8be4a
      Josh Bleecher Snyder authored
      Change-Id: I9882488e69565dc9da6814fefbdba3621daf74fe
      Reviewed-on: https://go-review.googlesource.com/59332
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: 's avatarMarvin Stenger <marvin.stenger94@gmail.com>
      53c8be4a
    • Ulrich Kunitz's avatar
      crypto/rsa: fix URL for the PKCS #1 v2.2 document in pss.go · eb070282
      Ulrich Kunitz authored
      The PKCS #1 v2.2 document has been moved to an EMC
      website with a new URL. This CL updates the reference to the document to
      the new URL.
      
      The new URL is referenced under https://en.wikipedia.org/wiki/PKCS_1
      
      Fixes #21642
      
      Change-Id: Ib8738b0c4c3bb9ec427bebea20c4aacd607ba0db
      Reviewed-on: https://go-review.googlesource.com/59351Reviewed-by: 's avatarEmmanuel Odeke <emm.odeke@gmail.com>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      eb070282
    • Rob Pike's avatar
      fmt: document verbs %b %d %o %x %X for printing pointers · a4140b74
      Rob Pike authored
      This has been supported since Go 1 and there's even a test for it.
      The documentation was missing.
      
      Fixes #21409.
      
      Change-Id: I5813488f6a98c1b4506c239e968d43344b91be12
      Reviewed-on: https://go-review.googlesource.com/59412Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      a4140b74
    • Dmitri Shuralyov's avatar
      cmd/go/internal/load: fix IsMetaPackage function name in doc · 2abef597
      Dmitri Shuralyov authored
      The IsMetaPackage function was made exported when it was moved from
      cmd/go to cmd/go/internal/load in CL 36196. Its documentation wasn't
      updated accordingly. This change fixes that, resolving a golint issue.
      
      Updates #18653.
      
      Change-Id: Icf89461000754d0f09e6617b11c838e4c050d5a6
      Reviewed-on: https://go-review.googlesource.com/59430Reviewed-by: 's avatarDave Cheney <dave@cheney.net>
      2abef597
  2. 27 Aug, 2017 1 commit
  3. 26 Aug, 2017 2 commits
  4. 25 Aug, 2017 26 commits
    • Joe Tsai's avatar
      archive/tar: improve package documentation · bad6b6fa
      Joe Tsai authored
      Many aspects of the package is woefully undocumented.
      With the recent flurry of improvements, the package is now at feature
      parity with the GNU and TAR tools. Thoroughly all of the public API
      and perform some minor stylistic cleanup in some code segments.
      
      Change-Id: Ic892fd72c587f30dfe91d1b25b88c9c8048cc389
      Reviewed-on: https://go-review.googlesource.com/59210
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      bad6b6fa
    • Joe Tsai's avatar
      archive/tar: add raw support for global PAX records · 19a99594
      Joe Tsai authored
      The PAX specification says the following:
      <<<
      'g' represents global extended header records for the following files in the archive.
      The format of these extended header records shall be as described in pax Extended Header.
      Each value shall affect all subsequent files that do not override that value
      in their own extended header record and until another global extended header record
      is reached that provides another value for the same field.
      >>>
      
      This CL adds support for parsing and composing global PAX records,
      but intentionally does not provide support for automatically
      persisting the global state across files.
      
      Changes made:
      * When Reader encounters a TypeXGlobalRecord header, it parses the
      PAX records and returns them to the user ad-verbatim. Reader does not
      store them in its state, ensuring it has no effect on future Next calls.
      * When Writer receives a TypeXGlobalRecord header, it writes the
      PAX records to the archive ad-verbatim. It does not store them in
      its state, ensuring it has no effect on future WriteHeader calls.
      * The restriction regarding empty record values is lifted since this
      value is used to represent deletion in global headers.
      
      Why provide raw support only:
      * Some archives in the wild have a global header section (often empty)
      and it is the user's responsibility to manually read and discard it's body.
      The logic added here allows users to more easily skip over these sections.
      * For users that do care about global headers, having access to the raw
      records allows them to implement the functionality of global headers themselves
      and manually persist the global state across files.
      * We can still upgrade to a full implementation in the future.
      
      Why we don't provide full support:
      * Even though the PAX specification describes their operation in detail,
      both the GNU and BSD tar tools (which are the most common implementations)
      do not have a consistent interpretation of many details.
      * Global headers were a controversial feature in PAX, by admission of the
      specification itself:
        <<<
        The concept of a global extended header (typeflag g) was controversial.
      
        The typeflag g global headers should not be used with interchange media that
        could suffer partial data loss in transporting the archive.
        >>>
      * Having state persist from entry-to-entry complicates the implementation
      for a feature that is not widely used and not well supported.
      
      Change-Id: I1d904cacc2623ddcaa91525a5470b7dbe226c7e8
      Reviewed-on: https://go-review.googlesource.com/59190Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      19a99594
    • Hiroshi Ioka's avatar
      cmd/link: fix debug message · 37b04c90
      Hiroshi Ioka authored
      Change-Id: I6cb0ed9b726da34106ba239b57e2da732a8e1b71
      Reviewed-on: https://go-review.googlesource.com/50730Reviewed-by: 's avatarMichael Hudson-Doyle <michael.hudson@canonical.com>
      Reviewed-by: 's avatarAvelino <t@avelino.xxx>
      37b04c90
    • Daniel Martí's avatar
      testing: error if -parallel is given N<1 · 86dde2de
      Daniel Martí authored
      Otherwise, if there are any parallel tests, it will hang and panic with
      "all goroutines are asleep - deadlock!".
      
      Do not use flag.Uint to handle the error for us because we also want to
      error on N==0, and because it would make setting the default to
      GOMAXPROCS(0) more difficult, since it's an int.
      
      Check for it right after flag.Parse, and mimic flag errors by printing
      the usage and returning exit code 2.
      
      Fixes #20542.
      
      Change-Id: I0c9d4587f83d406a8f5e42ed74e40be46d639ffb
      Reviewed-on: https://go-review.googlesource.com/54150
      Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      86dde2de
    • Meir Fischer's avatar
      testing: ensure profiles are written upon -timeout panic · 7e455b62
      Meir Fischer authored
      This addresses the case of a -timeout panic, but not the more
      general case of a signal arriving. See CL 48370 and CL 44352
      for recent difficulties in that area.
      
      "-timeout" here means flag usage to distinguish from the
      default timeout termination which uses signals.
      
      Fixes #19394
      
      Change-Id: I5452d5422c0c080e940cbcc8c6606049975268c6
      Reviewed-on: https://go-review.googlesource.com/48491Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      7e455b62
    • Artyom Pervukhin's avatar
      crypto/tls: fix docstring of Config.ClientSessionCache · 85deaf60
      Artyom Pervukhin authored
      Closes #21519
      
      Change-Id: I1247e9435de93aae7e4db2b6e8e5be1b010c296b
      Reviewed-on: https://go-review.googlesource.com/56832Reviewed-by: 's avatarAvelino <t@avelino.xxx>
      Reviewed-by: 's avatarAdam Langley <agl@golang.org>
      85deaf60
    • Joe Tsai's avatar
      archive/tar: support arbitrary PAX records · a795ca51
      Joe Tsai authored
      This CL adds the following new publicly visible API:
      	type Header struct { ...; PAXRecords map[string]string }
      
      The new Header.PAXRecords field is a map of all PAX extended header records.
      
      We suggest (but do not enforce) that users use VENDOR-prefixed keys
      according to the following in the PAX specification:
      <<<
      The standard developers have reserved keyword name space for vendor extensions.
      It is suggested that the format to be used is:
      	VENDOR.keyword
      where VENDOR is the name of the vendor or organization in all uppercase letters.
      >>>
      
      When reading, the Header.PAXRecords is populated with all PAX records
      encountered so far, including basic ones (e.g., "path", "mtime", etc).
      When writing, the fields of Header will be merged into PAXRecords,
      overwriting any records that may conflict.
      
      Since PAXRecords is a more expressive feature than Xattrs and
      is entirely a superset of Xattrs, we mark Xattrs as deprecated,
      and steer users towards the new PAXRecords API.
      
      The issue has a discussion about adding a Header.SetPAXRecord method
      to help validate records and keep the Header fields in sync.
      However, we do not include that in this CL since that helper
      method can always be added in the future.
      
      There is no support for global records.
      
      Fixes #14472
      
      Change-Id: If285a52749acc733476cf75a2c7ad15bc1542071
      Reviewed-on: https://go-review.googlesource.com/58390
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      a795ca51
    • Joe Tsai's avatar
      go/build: add go1.10 build tag · 4d6da864
      Joe Tsai authored
      Add this early in the cycle so that we can start regression testing
      of the master toolchain.
      
      Change-Id: Ida3ccad6e9642648f489babd12877fc8a5eca07a
      Reviewed-on: https://go-review.googlesource.com/59151Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      4d6da864
    • Ian Lance Taylor's avatar
      runtime: unify sigTabT type across Unix systems · 6126384f
      Ian Lance Taylor authored
      Change-Id: I8e8a3a118b1216f191c9076b70a88f6f3f19f79f
      Reviewed-on: https://go-review.googlesource.com/59150
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      6126384f
    • Borja Clemente's avatar
      bytes: Add missing examples to functions · 394f6a5a
      Borja Clemente authored
      Fixes #21570
      
      Change-Id: Ia0734929a04fbce8fdd5fbcb1b7baff9a8bbe39e
      Reviewed-on: https://go-review.googlesource.com/58030Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      Reviewed-by: 's avatarJoe Tsai <thebrokentoaster@gmail.com>
      Run-TryBot: Robert Griesemer <gri@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      394f6a5a
    • Tom Levy's avatar
      sort: fix mix-up between "!less" and "greater" in examples · 2bba2671
      Tom Levy authored
      If Less(a, b) returns true when a is less than b, the correct way to
      check if a is greater than b is to use Less(b, a). It is wrong to use
      !Less(a, b) because that checks if a is greater than *or equal to* b.
      
      1. The decreasingDistance function in Example_sortKeys makes this
         mistake. Fix it.
      
      2. The documentation of multiSorter.Less says it loops along the less
         functions until it finds a comparison "that is either Less or
         !Less". This is nonsense, because (Less(a, b) or !Less(a, b)) is
         always true. Fix the documentation to say that it finds a
         comparison "that discriminates between the two items (one is less
         than the other)". The implementation already does this correctly.
      
      Change-Id: If52b79f68e4fdb0d1095edf29bdecdf154a61b8d
      Reviewed-on: https://go-review.googlesource.com/57752Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      2bba2671
    • fanzha02's avatar
      cmd/internal/obj/arm64: fix assemble fcsels/fcseld bug · aea286b4
      fanzha02 authored
      The current code treats the type of SIMD&FP register as C_REG incorrectly.
      
      The fix code converts C_REG type into C_FREG type.
      
      Uncomment fcsels/fcseld test cases.
      
      Fixes #21582
      Change-Id: I754c51f72a0418bd352cbc0f7740f14cc599c72d
      Reviewed-on: https://go-review.googlesource.com/58350Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      aea286b4
    • Heschi Kreinick's avatar
      cmd/compile: bug fixes for DWARF location lists · 38bd725b
      Heschi Kreinick authored
      Fix two small but serious bugs in the DWARF location list code that
      should have been caught by the automated tests I didn't write.
      
      After emitting debug information for a user variable, mark it as done
      so that it doesn't get emitted again. Otherwise it would be written once
      per slot it was decomposed into.
      
      Correct a merge error in CL 44350: the location list abbreviations need
      to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish.
      
      Change-Id: I6ab4b8b32b7870981dac80eadf0ebfc4015ccb01
      Reviewed-on: https://go-review.googlesource.com/59070
      Run-TryBot: Heschi Kreinick <heschi@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      38bd725b
    • jaredculp's avatar
      math: add examples for trig functions · dc42ffff
      jaredculp authored
      Change-Id: Ic3ce2f3c055f2636ec8fc9cec8592e596b18dc05
      Reviewed-on: https://go-review.googlesource.com/54771
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      dc42ffff
    • Wei Xiao's avatar
      cmd/compile: memory clearing optimization for arm64 · c02fc160
      Wei Xiao authored
      Use "STP (ZR, ZR), O(R)" instead of "MOVD ZR, O(R)" to implement memory clearing.
      Also improve assembler supports to STP/LDP.
      Results (A57@2GHzx8):
      
      benchmark                   old ns/op     new ns/op     delta
      BenchmarkClearFat8-8        1.00          1.00          +0.00%
      BenchmarkClearFat12-8       1.01          1.01          +0.00%
      BenchmarkClearFat16-8       1.01          1.01          +0.00%
      BenchmarkClearFat24-8       1.52          1.52          +0.00%
      BenchmarkClearFat32-8       3.00          2.02          -32.67%
      BenchmarkClearFat40-8       3.50          2.52          -28.00%
      BenchmarkClearFat48-8       3.50          3.03          -13.43%
      BenchmarkClearFat56-8       4.00          3.50          -12.50%
      BenchmarkClearFat64-8       4.25          4.00          -5.88%
      BenchmarkClearFat128-8      8.01          8.01          +0.00%
      BenchmarkClearFat256-8      16.1          16.0          -0.62%
      BenchmarkClearFat512-8      32.1          32.0          -0.31%
      BenchmarkClearFat1024-8     64.1          64.1          +0.00%
      
      Change-Id: Ie5f5eac271ff685884775005825f206167a5c146
      Reviewed-on: https://go-review.googlesource.com/55610
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      c02fc160
    • Ilya Tocar's avatar
      cmd/compile/internal/ssa: combine consecutive loads and stores on amd64 · 9c99512d
      Ilya Tocar authored
      Sometimes (often for calls) we generate code like this:
      
      MOVQ  (addr),AX
      MOVQ  8(addr),BX
      MOVQ  AX,(otheraddr)
      MOVQ  BX,8(otheraddr)
      
      Replace it with
      
      MOVUPS (addr),X0
      MOVUPS X0,(otheraddr)
      
      For completeness do the same for 8,16,32-bit loads/stores too.
      Shaves 1% from code sections of go tool.
      
      /localdisk/itocar/golang/bin/go 10293917
      go_old 10334877 [40960 bytes]
      
      read-only data = 682 bytes (0.040769%)
      global text (code) = 38961 bytes (1.036503%)
      Total difference 39643 bytes (0.674628%)
      
      Updates #6853
      
      Change-Id: I1f0d2f60273a63a079b58927cd1c4e3429d2e7ae
      Reviewed-on: https://go-review.googlesource.com/57130
      Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      9c99512d
    • griesemer's avatar
      spec: explicitly define notion of "representability" (clarification) · b40831b1
      griesemer authored
      Throughout the spec we use the notion of a constant x being
      representable by a value of type T. While intuitively clear,
      at least for floating-point and complex constants types, the
      concept was not well-defined. In the section on Conversions
      there was an extra rule for floating-point types only and it
      missed the case of floating-point values overflowing to an
      infinity after rounding.
      
      Since the concept is important to Go, and a compiler most
      certainly will have a function to test "representability",
      it seems warranted to define the term explicitly in the spec.
      
      This change introduces a new entry "Representability" under
      the section on "Properties of types and values", and defines
      the term explicitly, together with examples.
      
      The phrase used is "representable by" rather than "representable as"
      because the former use is prevalent in the spec.
      
      Additionally, it clarifies that a floating-point constant
      that overflows to an infinity after rounding is never
      representable by a value of a floating-point type, even though
      infinities are valid values of IEEE floating point types.
      This is required because there are not infinite value constants
      in the language (like there is also no -0.0) and representability
      also matters for constant conversions. This is not a language
      change, and type-checkers have been following this rule before.
      
      The change also introduces links throughout the spec to the new
      section as appropriate and removes duplicate text and examples
      elsewhere (Constants and Conversions sections), leading to
      simplifications in the relevant paragraphs.
      
      Fixes #15389.
      
      Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
      Reviewed-on: https://go-review.googlesource.com/57530Reviewed-by: 's avatarRob Pike <r@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      b40831b1
    • Josh Bleecher Snyder's avatar
      runtime: optimize storing new keys in mapassign_fastNN · 25bbb695
      Josh Bleecher Snyder authored
      Prior to this change, we use typedmemmove to write the key
      value to its new location in mapassign_fast32 and mapassign_fast64.
      (The use of typedmemmove was a last-minute fix in the 1.9 cycle;
      see #21297 and CL 53414.)
      
      This is significantly less inefficient than direct assignment or
      calling writebarrierptr directly.
      
      Fortunately, there aren't many cases to consider.
      
      On systems with 32 bit pointers:
      
      * A 32 bit AMEM value either is a single pointer or has no pointers.
      * A 64 bit AMEM value may contain a pointer at the beginning,
        a pointer at 32 bits, or two pointers.
      
      On systems with 64 bit pointers:
      
      * A 32 bit AMEM value contains no pointers.
      * A 64 bit AMEM value either is a single pointer or has no pointers.
      
      All combinations except the 32 bit pointers / 64 bit AMEM value are
      cheap and easy to handle, and the problematic case is likely rare.
      The most popular map keys appear to be ints and pointers.
      
      So we handle them exhaustively. The sys.PtrSize checks are constant branches
      and are eliminated by the compiler.
      
      An alternative fix would be to return a pointer to the key,
      and have the calling code do the assignment, at which point the compiler
      would have full type information.
      
      Initial tests suggest that the performance difference between these
      strategies is negligible, and this fix is considerably simpler,
      and has much less impact on binary size.
      
      Fixes #21321
      
      Change-Id: Ib03200e89e2324dd3c76d041131447df66f22bfe
      Reviewed-on: https://go-review.googlesource.com/59110
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarAustin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      25bbb695
    • Josh Bleecher Snyder's avatar
      cmd/compile: enforce that MOVXconvert is a no-op on 386 and amd64 · a45d6859
      Josh Bleecher Snyder authored
      Follow-up to CL 58371.
      
      Change-Id: I3d2aaec84ee6db3ef1bd4fcfcaf46cc297c7176b
      Reviewed-on: https://go-review.googlesource.com/58610
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      a45d6859
    • Keith Randall's avatar
      cmd/compile,math: improve code generation for math.Abs · fb05948d
      Keith Randall authored
      Implement int reg <-> fp reg moves on amd64.
      If we see a load to int reg followed by an int->fp move, then we can just
      load to the fp reg instead.  Same for stores.
      
      math.Abs is now:
      
      MOVQ	"".x+8(SP), AX
      SHLQ	$1, AX
      SHRQ	$1, AX
      MOVQ	AX, "".~r1+16(SP)
      
      math.Copysign is now:
      
      MOVQ	"".x+8(SP), AX
      SHLQ	$1, AX
      SHRQ	$1, AX
      MOVQ	"".y+16(SP), CX
      SHRQ	$63, CX
      SHLQ	$63, CX
      ORQ	CX, AX
      MOVQ	AX, "".~r2+24(SP)
      
      math.Float64bits is now:
      
      MOVSD	"".x+8(SP), X0
      MOVSD	X0, "".~r1+16(SP)
      (it would be nicer to use a non-SSE reg for this, nothing is perfect)
      
      And due to the fix for #21440, the inlined version of these improve as well.
      
      name      old time/op  new time/op  delta
      Abs       1.38ns ± 5%  0.89ns ±10%  -35.54%  (p=0.000 n=10+10)
      Copysign  1.56ns ± 7%  1.35ns ± 6%  -13.77%  (p=0.000 n=9+10)
      
      Fixes #13095
      
      Change-Id: Ibd7f2792412a6668608780b0688a77062e1f1499
      Reviewed-on: https://go-review.googlesource.com/58732
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: 's avatarIlya Tocar <ilya.tocar@intel.com>
      fb05948d
    • Kevin Burke's avatar
      path/filepath: add example for Ext · e11fd006
      Kevin Burke authored
      Make it dead simple to see visually what the function outputs in
      various scenarios.
      
      Change-Id: I8f6fcd72fa1515361481f0510412cde221e1d4e3
      Reviewed-on: https://go-review.googlesource.com/51630
      Run-TryBot: Kevin Burke <kev@inburke.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarJosh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: 's avatarHiroshi Ioka <hirochachacha@gmail.com>
      e11fd006
    • Austin Clements's avatar
      runtime: capture runtimeInitTime after nanotime is initialized · 9d17e175
      Austin Clements authored
      CL 36428 changed the way nanotime works so on Darwin and Windows it
      now depends on runtime.startNano, which is computed at runtime.init
      time. Unfortunately, the `runtimeInitTime = nanotime()` initialization
      happened *before* runtime.init, so on these platforms runtimeInitTime
      is set incorrectly. The one (and only) consequence of this is that the
      start time printed in gctrace lines is bogus:
      
      gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P
      
      To fix this, this commit moves the runtimeInitTime initialization to
      shortly after runtime.init, at which point nanotime is safe to use.
      
      This also requires changing the condition in newproc1 that currently
      uses runtimeInitTime != 0 simply to detect whether or not the main M
      has started. Since runtimeInitTime could genuinely be 0 now, this
      introduces a separate flag to newproc1.
      
      Fixes #21554.
      
      Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b
      Reviewed-on: https://go-review.googlesource.com/58690
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRick Hudson <rlh@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      9d17e175
    • Hana Kim's avatar
      misc/trace: update trace-viewer · 05ff6bfe
      Hana Kim authored
      Generated with
       github.com/catapult/tracing/bin/vulcanize_trace_viewer
      catapult @ ab4d571fa
      
      Renamed trace_viewer_lean.html to trace_viewer_full.html
      to make it clear we are using the full version of trace viewer
      (waiting for https://github.com/catapult-project/catapult/issues/2247
      to be fixed).
      
      Update #15302
      
      Change-Id: Ice808bb27ab79a1dec9fc863e0c5a761027ebfbe
      Reviewed-on: https://go-review.googlesource.com/58750Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      05ff6bfe
    • Wei Xiao's avatar
      cmd/vendor/golang.org/x/arch: pull latest updates from x repo (commit edaf650) · 1708122b
      Wei Xiao authored
      Updates #21486
      
      Change-Id: I78ca76490d8e9b52e055c1f0b8d10bdb227e3a80
      Reviewed-on: https://go-review.googlesource.com/56331Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      1708122b
    • Danny Rosseau's avatar
      encoding/gob: fix Debug to properly print uint · 9515610a
      Danny Rosseau authored
      Fix debugger printing of uint that mistakenly
      invoked .int64() instead of .uint64()
      
      Fixes #21392
      
      Change-Id: I107a7e87e0efbb06303c1e627dee76c369f75d1e
      Reviewed-on: https://go-review.googlesource.com/54750Reviewed-by: 's avatarEmmanuel Odeke <emm.odeke@gmail.com>
      Reviewed-by: 's avatarRob Pike <r@golang.org>
      Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9515610a
    • Aliaksandr Valialkin's avatar
      strconv: optimize Atoi for common case · 46aa9f54
      Aliaksandr Valialkin authored
      Benchmark results on GOOS=linux:
      
      GOARCH=amd64
      
      name              old time/op  new time/op  delta
      Atoi/Pos/7bit-4   20.1ns ± 2%   8.6ns ± 1%  -57.34%  (p=0.000 n=10+10)
      Atoi/Pos/26bit-4  25.8ns ± 7%  11.9ns ± 0%  -53.91%  (p=0.000 n=10+8)
      Atoi/Pos/31bit-4  27.3ns ± 2%  13.2ns ± 1%  -51.56%  (p=0.000 n=10+10)
      Atoi/Pos/56bit-4  37.2ns ± 5%  18.2ns ± 1%  -51.26%  (p=0.000 n=10+10)
      Atoi/Pos/63bit-4  38.7ns ± 1%  38.6ns ± 1%     ~     (p=0.297 n=9+10)
      Atoi/Neg/7bit-4   17.6ns ± 1%   7.2ns ± 0%  -59.22%  (p=0.000 n=10+10)
      Atoi/Neg/26bit-4  24.4ns ± 1%  12.4ns ± 1%  -49.28%  (p=0.000 n=10+10)
      Atoi/Neg/31bit-4  26.9ns ± 0%  14.0ns ± 1%  -47.88%  (p=0.000 n=7+10)
      Atoi/Neg/56bit-4  36.2ns ± 1%  19.5ns ± 0%  -46.24%  (p=0.000 n=10+9)
      Atoi/Neg/63bit-4  38.9ns ± 1%  38.8ns ± 1%     ~     (p=0.385 n=9+10)
      
      GOARCH=386
      
      name              old time/op  new time/op  delta
      Atoi/Pos/7bit-4   89.6ns ± 1%   8.2ns ± 1%  -90.84%  (p=0.000 n=9+10)
      Atoi/Pos/26bit-4   187ns ± 2%    12ns ± 1%  -93.71%  (p=0.000 n=10+9)
      Atoi/Pos/31bit-4   225ns ± 1%   225ns ± 1%     ~     (p=0.995 n=10+10)
      Atoi/Neg/7bit-4   86.2ns ± 1%   8.5ns ± 1%  -90.14%  (p=0.000 n=10+10)
      Atoi/Neg/26bit-4   183ns ± 1%    13ns ± 1%  -92.77%  (p=0.000 n=9+10)
      Atoi/Neg/31bit-4   223ns ± 0%   223ns ± 0%     ~     (p=0.247 n=8+9)
      
      Fixes #20557
      
      Change-Id: Ib6245d88cffd4b037419e2bf8e4a71b86c6d773f
      Reviewed-on: https://go-review.googlesource.com/44692Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      46aa9f54