1. 22 May, 2018 3 commits
    • Austin Clements's avatar
      cmd/compile: derive len/cap relations in factsTable.update · 4816efac
      Austin Clements authored
      Currently, the prove pass derives implicit relations between len and
      cap in the code that adds branch conditions. This is fine right now
      because that's the only place we can encounter len and cap, but we're
      about to add a second way to add assertions to the facts table that
      can also produce facts involving len and cap.
      
      Prepare for this by moving the fact derivation from updateRestrictions
      (where it only applies on branches) to factsTable.update, which can
      derive these facts no matter where the root facts come from.
      
      Passes toolstash -cmp.
      
      Change-Id: If09692d9eb98ffaa93f4cfa58ed2d8ba0887c111
      Reviewed-on: https://go-review.googlesource.com/102602
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      4816efac
    • Austin Clements's avatar
      cmd/compile: teach prove about relations between constants · 8d8f620f
      Austin Clements authored
      Currently, we never add a relation between two constants to prove's
      fact table because these are eliminated before prove runs, so it
      currently doesn't handle facts like this very well even though they're
      easy to prove.
      
      We're about to start asserting some conditions that don't appear in
      the SSA, but are constructed from existing SSA values that may both be
      constants.
      
      Hence, improve the fact table to understand relations between
      constants by initializing the constant bounds of constant values to
      the value itself, rather than noLimit.
      
      Passes toolstash -cmp.
      
      Change-Id: I71f8dc294e59f19433feab1c10b6d3c99b7f1e26
      Reviewed-on: https://go-review.googlesource.com/102601
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      8d8f620f
    • David Chase's avatar
      cmd/compile: refactor inlining parameters; inline panic · 87a18c61
      David Chase authored
      Inlining was refactored to perform tuning experiments,
      with the "knobs" now set to also inline functions/methods
      that include panic(), and -l=4 (inline calls) now expressed
      as a change to costs, rather than scattered if-thens.
      
      The -l=4 inline-calls penalty is chosen to be the best
      found during experiments; it makes some programs much
      larger and slower (notably, the compiler itself) and is
      believed to be risky for machine-generated code in general,
      which is why it is not the default.  It is also not
      well-tested with the debugger and DWARF output.
      
      This change includes an explicit go:noinline applied to the
      method that is the largest cause of compiler binary growth
      and slowdown for midstack inlining; there are others,
      ideally whatever heuristic eventually appears will make
      this unnecessary.
      
      Change-Id: Idf7056ed2f961472cf49d2fd154ee98bef9421e2
      Reviewed-on: https://go-review.googlesource.com/109918
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      87a18c61
  2. 21 May, 2018 11 commits
  3. 20 May, 2018 1 commit
    • Keith Randall's avatar
      runtime: use libc for nanotime on Darwin · cc09212f
      Keith Randall authored
      Use mach_absolute_time and mach_timebase_info to get nanosecond-level
      timing information from libc on Darwin.
      
      The conversion code from Apple's arbitrary time unit to nanoseconds is
      really annoying.  It would be nice if we could replace the internal
      runtime "time" with arbitrary units and put the conversion to nanoseconds
      only in the places that really need it (so it isn't in every nanotime call).
      
      It's especially annoying because numer==denom==1 for all the machines
      I tried.  Makes it hard to test the conversion code :(
      
      Update #17490
      
      Change-Id: I6c5d602a802f5c24e35184e33d5e8194aa7afa86
      Reviewed-on: https://go-review.googlesource.com/110655
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      cc09212f
  4. 19 May, 2018 2 commits
    • Keith Randall's avatar
      runtime: fix darwin 386/amd64 stack switches · e86c2678
      Keith Randall authored
      A few libc_ calls were missing stack switches.
      
      Unfortunately, adding the stack switches revealed a deeper problem.
      systemstack() is fundamentally flawed because when you do
      
          systemstack(func() { ... })
      
      There's no way to mark the anonymous function as nosplit.  At first I
      thought it didn't matter, as that function runs on the g0 stack.  But
      nosplit is still required, because some syscalls are done when stack
      bounds are not set up correctly (e.g. in a signal handler, which runs
      on the g0 stack, but g is still pointing at the g stack).  Instead use
      asmcgocall and funcPC, so we can be nosplit all the way down.
      
      Mid-stack inlining now pushes darwin over the nosplit limit also.
      Leaving that as a TODO.
      Update #23168
      
      This might fix the cause of occasional darwin hangs.
      Update #25181
      
      Update #17490
      
      Change-Id: If9c3ef052822c7679f5a1dd192443f714483327e
      Reviewed-on: https://go-review.googlesource.com/111258Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      e86c2678
    • Ali Rizvi-Santiago's avatar
      debug/pe: parse the import directory correctly · e9137299
      Ali Rizvi-Santiago authored
      This parses the import table properly which allows for debug/pe
      to extract import symbols from pecoffs linked with an import
      table in a section named something other than ".idata"
      
      The section names in a pecoff object aren't guaranteed to actually
      mean anything, so hardcoding a search for the ".idata" section
      is not guaranteed to find the import table in all shared libraries.
      This resulted in debug/pe being unable to read import symbols
      from some libraries.
      
      The proper way to locate the import table is to validate the
      number of data directory entries, locate the import entry, and
      then use the va to identify the section containing the import
      table. This patch does exactly this.
      
      Fixes #16103.
      
      Change-Id: I3ab6de7f896a0c56bb86c3863e504e8dd4c8faf3
      GitHub-Last-Rev: ce8077cb154f18ada7a86e152ab03de813937816
      GitHub-Pull-Request: golang/go#25193
      Reviewed-on: https://go-review.googlesource.com/110555
      Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarAlex Brainman <alex.brainman@gmail.com>
      e9137299
  5. 18 May, 2018 5 commits
  6. 17 May, 2018 7 commits
  7. 16 May, 2018 6 commits
  8. 15 May, 2018 5 commits
    • Rob Pike's avatar
      doc/contribute.html: English cleanups · 3868a371
      Rob Pike authored
      Fixes #24487
      
      Change-Id: Ic523e469f7f67f376edd2fca6e07d35bb11b2db9
      Reviewed-on: https://go-review.googlesource.com/113016Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      3868a371
    • Michael Munday's avatar
      cmd/compile: improve error message emitted by debug info generation · 3797f88f
      Michael Munday authored
      Before:
      
      unexpected at 2721:load with unexpected source op v3278unexpected at 2775:load with
      unexpected source op v3281unexpected at 2249:load with unexpected source op
      v3289unexpected at 2875:load with unexpected source op v3278unexpected at 2232:load
      with unexpected source op v286unexpected at 2231:load with unexpected source op
      v3291unexpected at 2784:load with unexpected source op v3289unexpected at 2785:load
      with unexpected source op v3291
      
      After:
      
      debug info generation: v2721: load with unexpected source op: Phi (v3278)
      debug info generation: v2775: load with unexpected source op: Phi (v3281)
      debug info generation: v2249: load with unexpected source op: Phi (v3289)
      debug info generation: v2875: load with unexpected source op: Phi (v3278)
      debug info generation: v2232: load with unexpected source op: Phi (v286)
      debug info generation: v2231: load with unexpected source op: Phi (v3291)
      debug info generation: v2784: load with unexpected source op: Phi (v3289)
      debug info generation: v2785: load with unexpected source op: Phi (v3291)
      
      Updates #25404.
      
      Change-Id: Ib97722848d27ca18bdcd482a610626bc3c6def7d
      Reviewed-on: https://go-review.googlesource.com/113275
      Run-TryBot: Michael Munday <mike.munday@ibm.com>
      Run-TryBot: Heschi Kreinick <heschi@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarHeschi Kreinick <heschi@google.com>
      3797f88f
    • Michael Munday's avatar
      vendor/golang_org/x/crypto: revendor · 212c9479
      Michael Munday authored
      This change updates the vendored copy of golang.org/x/crypto to
      commit 1a580b3eff7814fc9b40602fd35256c63b50f491.
      
      An import of golang.org/x/sys/cpu was replaced with an import of
      internal/cpu as required by
      https://github.com/golang/go/issues/24843#issuecomment-383194779.
      
      The following bash command can be used to replicate this import
      update:
      
      find `pwd` -name '*.go' -exec sed -i 's/golang\.org\/x\/sys\/cpu/internal\/cpu/g' '{}' \;
      
      Change-Id: Ic80d361f940a96c70e4196f594d791c63421d73c
      Reviewed-on: https://go-review.googlesource.com/113175Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      212c9479
    • isharipo's avatar
      mime: do a pre-allocation in encodeWord · 3fb3ca08
      isharipo authored
      The preallocated memory size is comparable to bytes.Buffer bootstraping
      array length (bytes.Buffer was used before rewrite to strings.Builder).
      
      Without preallocation, encodeWord does more than one allocation for
      almost any possible input.
      
      The regression happens because bytes.Buffer did a 80-bytes allocation
      at the beginning of encodeWord while strings.Builder did several
      smaller allocations (started with cap=0).
      
      Comparison with reported regression:
      
        name           old time/op    new time/op    delta
        QEncodeWord-4     781ns ± 1%     593ns ± 1%  -24.08%  (p=0.008 n=5+5)
      
        name           old alloc/op   new alloc/op   delta
        QEncodeWord-4      152B ± 0%       80B ± 0%  -47.37%  (p=0.008 n=5+5)
      
        name           old allocs/op  new allocs/op  delta
        QEncodeWord-4      5.00 ± 0%      2.00 ± 0%  -60.00%  (p=0.008 n=5+5)
      
      Comparison with buffer solution (like before strings.Builder, but
      without sync pool for buffer re-using):
      
        name           old time/op    new time/op    delta
        QEncodeWord-4     595ns ± 1%     593ns ± 1%     ~     (p=0.460 n=5+5)
      
        name           old alloc/op   new alloc/op   delta
        QEncodeWord-4      160B ± 0%       80B ± 0%  -50.00%  (p=0.008 n=5+5)
      
        name           old allocs/op  new allocs/op  delta
        QEncodeWord-4      2.00 ± 0%      2.00 ± 0%     ~     (all equal)
      
      We avoid allocation in buf.String(), as expected.
      
      Fixes #25379
      
      Change-Id: I19763f0e593a27390c1a549b86ce6507b489046b
      Reviewed-on: https://go-review.googlesource.com/113235
      Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      3fb3ca08
    • Richard Musiol's avatar
      misc/wasm: fix passing large negative integers from JS to Go · 73b59513
      Richard Musiol authored
      This commit addresses a FIXME left in the code of wasm_exec.js to
      properly get the upper 32 bit of a JS number to be stored as an
      64-bit integer. A bitshift operation is not possible, because in
      JavaScript bitshift operations only operate on the lower 32 bits.
      
      Change-Id: I8f627fd604e592682d9d322942a4852db64a7f66
      Reviewed-on: https://go-review.googlesource.com/113076Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      73b59513