An error occurred fetching the project authors.
  1. 09 Mar, 2016 2 commits
  2. 08 Mar, 2016 1 commit
  3. 07 Mar, 2016 1 commit
  4. 05 Mar, 2016 1 commit
  5. 03 Mar, 2016 2 commits
  6. 02 Mar, 2016 2 commits
  7. 29 Feb, 2016 1 commit
  8. 27 Feb, 2016 1 commit
  9. 26 Feb, 2016 1 commit
    • Ian Lance Taylor's avatar
      cmd/compile: change Func.{Dcl,Inldcl} from NodeList to slice · b66a8923
      Ian Lance Taylor authored
      A slice uses less memory than a NodeList, and has better memory locality
      when walking the list.
      
      This uncovered a tricky case involving closures: the escape analysis
      pass when run on a closure was appending to the Dcl list of the OCLOSURE
      rather than the ODCLFUNC.  This happened to work because they shared the
      same NodeList.  Fixed with a change to addrescapes, and a check to
      Tempname to catch any recurrences.
      
      This removes the last use of the listsort function outside of tests.
      I'll send a separate CL to remove it.
      
      Unfortunately, while this passes all tests, it does not pass toolstash
      -cmp.  The problem is that cmpstackvarlt does not fully determine the
      sort order, and the change from listsort to sort.Sort, while generally
      desirable, produces a different ordering.  I could stage this by first
      making cmpstackvarlt fully determined, but no matter what toolstash -cmp
      is going to break at some point.
      
      In my casual testing the compiler is 2.2% faster.
      
      Update #14473.
      
      Change-Id: I367d66daa4ec73ed95c14c66ccda3a2133ad95d5
      Reviewed-on: https://go-review.googlesource.com/19919Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      b66a8923
  10. 12 Feb, 2016 1 commit
    • Keith Randall's avatar
      cmd/compile: add write barrier to type switch · e3033fc5
      Keith Randall authored
      Type switches need write barriers if the written-to
      variable is heap allocated.
      
      For the added needwritebarrier call, the right arg doesn't
      really matter, I just pass something that will never disqualify
      the write barrier.  The left arg is the one that matters.
      
      Fixes #14306
      
      Change-Id: Ic2754167cce062064ea2eeac2944ea4f77cc9c3b
      Reviewed-on: https://go-review.googlesource.com/19481Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      e3033fc5
  11. 27 Jan, 2016 1 commit
  12. 14 Jan, 2016 1 commit
    • Russ Cox's avatar
      cmd/compile: recognize Syscall-like functions for liveness analysis · 1ac637c7
      Russ Cox authored
      Consider this code:
      
      	func f(*int)
      
      	func g() {
      		p := new(int)
      		f(p)
      	}
      
      where f is an assembly function.
      In general liveness analysis assumes that during the call to f, p is dead
      in this frame. If f has retained p, p will be found alive in f's frame and keep
      the new(int) from being garbage collected. This is all correct and works.
      We use the Go func declaration for f to give the assembly function
      liveness information (the arguments are assumed live for the entire call).
      
      Now consider this code:
      
      	func h1() {
      		p := new(int)
      		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
      	}
      
      Here syscall.Syscall is taking the place of f, but because its arguments
      are uintptr, the liveness analysis and the garbage collector ignore them.
      Since p is no longer live in h once the call starts, if the garbage collector
      scans the stack while the system call is blocked, it will find no reference
      to the new(int) and reclaim it. If the kernel is going to write to *p once
      the call finishes, reclaiming the memory is a mistake.
      
      We can't change the arguments or the liveness information for
      syscall.Syscall itself, both for compatibility and because sometimes the
      arguments really are integers, and the garbage collector will get quite upset
      if it finds an integer where it expects a pointer. The problem is that
      these arguments are fundamentally untyped.
      
      The solution we have taken in the syscall package's wrappers in past
      releases is to insert a call to a dummy function named "use", to make
      it look like the argument is live during the call to syscall.Syscall:
      
      	func h2() {
      		p := new(int)
      		syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
      		use(unsafe.Pointer(p))
      	}
      
      Keeping p alive during the call means that if the garbage collector
      scans the stack during the system call now, it will find the reference to p.
      
      Unfortunately, this approach is not available to users outside syscall,
      because 'use' is unexported, and people also have to realize they need
      to use it and do so. There is much existing code using syscall.Syscall
      without a 'use'-like function. That code will fail very occasionally in
      mysterious ways (see #13372).
      
      This CL fixes all that existing code by making the compiler do the right
      thing automatically, without any code modifications. That is, it takes h1
      above, which is incorrect code today, and makes it correct code.
      
      Specifically, if the compiler sees a foreign func definition (one
      without a body) that has uintptr arguments, it marks those arguments
      as "unsafe uintptrs". If it later sees the function being called
      with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
      as having escaped, and it makes sure to hold x in a live temporary
      variable until the call returns, so that the garbage collector cannot
      reclaim whatever heap memory x points to.
      
      For now I am leaving the explicit calls to use in package syscall,
      but they can be removed early in a future cycle (likely Go 1.7).
      
      The rule has no effect on escape analysis, only on liveness analysis.
      
      Fixes #13372.
      
      Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
      Reviewed-on: https://go-review.googlesource.com/18584Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      1ac637c7
  13. 30 Oct, 2015 1 commit
  14. 23 Oct, 2015 1 commit
  15. 07 Sep, 2015 1 commit
  16. 01 Sep, 2015 2 commits
  17. 31 Aug, 2015 1 commit
  18. 28 Jul, 2015 1 commit
    • Josh Bleecher Snyder's avatar
      [dev.ssa] cmd/compile: implement static data generation · 6b416650
      Josh Bleecher Snyder authored
      The existing backend recognizes special
      assignment statements as being implementable
      with static data rather than code.
      Unfortunately, it assumes that it is in the middle
      of codegen; it emits data and modifies the AST.
      
      This does not play well with SSA's two-phase
      bootstrapping approach, in which we attempt to
      compile code but fall back to the existing backend
      if something goes wrong.
      
      To work around this:
      
      * Add the ability to inquire about static data
      without side-effects.
      * Save the static data required for a function.
      * Emit that static data during SSA codegen.
      
      Change-Id: I2e8a506c866ea3e27dffb597095833c87f62d87e
      Reviewed-on: https://go-review.googlesource.com/12790Reviewed-by: default avatarKeith Randall <khr@golang.org>
      6b416650
  19. 23 Jul, 2015 1 commit
  20. 04 Jun, 2015 1 commit
  21. 03 Jun, 2015 7 commits
  22. 28 May, 2015 1 commit
  23. 21 May, 2015 1 commit
  24. 15 May, 2015 5 commits
  25. 14 May, 2015 1 commit
  26. 13 May, 2015 1 commit
    • Russ Cox's avatar
      cmd/internal/gc: optimize slice + write barrier · d4472799
      Russ Cox authored
      The code generated for a slice x[i:j] or x[i:j:k] computes the entire
      new slice (base, len, cap) and then uses it as the evaluation of the
      slice expression.
      
      If the slice is part of an update x = x[i:j] or x = x[i:j:k], there are
      opportunities to avoid computing some of these fields.
      
      For x = x[0:i], we know that only the len is changing;
      base can be ignored completely, and cap can be left unmodified.
      
      For x = x[0:i:j], we know that only len and cap are changing;
      base can be ignored completely.
      
      For x = x[i:i], we know that the resulting cap is zero, and we don't
      adjust the base during a slice producing a zero-cap result,
      so again base can be ignored completely.
      
      No write to base, no write barrier.
      
      The old slice code was trying to work at a Go syntax level, mainly
      because that was how you wrote code just once instead of once
      per architecture. Now the compiler is factored a bit better and we
      can implement slice during code generation but still have one copy
      of the code. So the new code is working at that lower level.
      (It must, to update only parts of the result.)
      
      This CL by itself:
      name                   old mean              new mean              delta
      BinaryTree17            5.81s × (0.98,1.03)   5.71s × (0.96,1.05)     ~    (p=0.101)
      Fannkuch11              4.35s × (1.00,1.00)   4.39s × (1.00,1.00)   +0.79% (p=0.000)
      FmtFprintfEmpty        86.0ns × (0.94,1.11)  82.6ns × (0.98,1.04)   -3.86% (p=0.048)
      FmtFprintfString        276ns × (0.98,1.04)   273ns × (0.98,1.02)     ~    (p=0.235)
      FmtFprintfInt           274ns × (0.98,1.06)   270ns × (0.99,1.01)     ~    (p=0.119)
      FmtFprintfIntInt        506ns × (0.99,1.01)   475ns × (0.99,1.01)   -6.02% (p=0.000)
      FmtFprintfPrefixedInt   391ns × (0.99,1.01)   393ns × (1.00,1.01)     ~    (p=0.139)
      FmtFprintfFloat         566ns × (0.99,1.01)   574ns × (1.00,1.01)   +1.33% (p=0.001)
      FmtManyArgs            1.91µs × (0.99,1.01)  1.87µs × (0.99,1.02)   -1.83% (p=0.000)
      GobDecode              15.3ms × (0.99,1.02)  15.0ms × (0.98,1.05)   -1.84% (p=0.042)
      GobEncode              11.5ms × (0.97,1.03)  11.4ms × (0.99,1.03)     ~    (p=0.152)
      Gzip                    645ms × (0.99,1.01)   647ms × (0.99,1.01)     ~    (p=0.265)
      Gunzip                  142ms × (1.00,1.00)   143ms × (1.00,1.01)   +0.90% (p=0.000)
      HTTPClientServer       90.5µs × (0.97,1.04)  88.5µs × (0.99,1.03)   -2.27% (p=0.014)
      JSONEncode             32.0ms × (0.98,1.03)  29.6ms × (0.98,1.01)   -7.51% (p=0.000)
      JSONDecode              114ms × (0.99,1.01)   104ms × (1.00,1.01)   -8.60% (p=0.000)
      Mandelbrot200          6.04ms × (1.00,1.01)  6.02ms × (1.00,1.00)     ~    (p=0.057)
      GoParse                6.47ms × (0.97,1.05)  6.37ms × (0.97,1.04)     ~    (p=0.105)
      RegexpMatchEasy0_32     171ns × (0.93,1.07)   152ns × (0.99,1.01)  -11.09% (p=0.000)
      RegexpMatchEasy0_1K     550ns × (0.98,1.01)   530ns × (1.00,1.00)   -3.78% (p=0.000)
      RegexpMatchEasy1_32     135ns × (0.99,1.02)   134ns × (0.99,1.01)   -1.33% (p=0.002)
      RegexpMatchEasy1_1K     879ns × (1.00,1.01)   865ns × (1.00,1.00)   -1.58% (p=0.000)
      RegexpMatchMedium_32    243ns × (1.00,1.00)   233ns × (1.00,1.00)   -4.30% (p=0.000)
      RegexpMatchMedium_1K   70.3µs × (1.00,1.00)  69.5µs × (1.00,1.00)   -1.13% (p=0.000)
      RegexpMatchHard_32     3.82µs × (1.00,1.01)  3.74µs × (1.00,1.00)   -1.95% (p=0.000)
      RegexpMatchHard_1K      117µs × (1.00,1.00)   115µs × (1.00,1.00)   -1.69% (p=0.000)
      Revcomp                 917ms × (0.97,1.04)   920ms × (0.97,1.04)     ~    (p=0.786)
      Template                114ms × (0.99,1.01)   117ms × (0.99,1.01)   +2.58% (p=0.000)
      TimeParse               622ns × (0.99,1.01)   615ns × (0.99,1.00)   -1.06% (p=0.000)
      TimeFormat              665ns × (0.99,1.01)   654ns × (0.99,1.00)   -1.70% (p=0.000)
      
      This CL and previous CL (append) combined:
      name                   old mean              new mean              delta
      BinaryTree17            5.68s × (0.97,1.04)   5.71s × (0.96,1.05)     ~    (p=0.638)
      Fannkuch11              4.41s × (0.98,1.03)   4.39s × (1.00,1.00)     ~    (p=0.474)
      FmtFprintfEmpty        92.7ns × (0.91,1.16)  82.6ns × (0.98,1.04)  -10.89% (p=0.004)
      FmtFprintfString        281ns × (0.96,1.08)   273ns × (0.98,1.02)     ~    (p=0.078)
      FmtFprintfInt           288ns × (0.97,1.06)   270ns × (0.99,1.01)   -6.37% (p=0.000)
      FmtFprintfIntInt        493ns × (0.97,1.04)   475ns × (0.99,1.01)   -3.53% (p=0.002)
      FmtFprintfPrefixedInt   423ns × (0.97,1.04)   393ns × (1.00,1.01)   -7.07% (p=0.000)
      FmtFprintfFloat         598ns × (0.99,1.01)   574ns × (1.00,1.01)   -4.02% (p=0.000)
      FmtManyArgs            1.89µs × (0.98,1.05)  1.87µs × (0.99,1.02)     ~    (p=0.305)
      GobDecode              14.8ms × (0.98,1.03)  15.0ms × (0.98,1.05)     ~    (p=0.237)
      GobEncode              12.3ms × (0.98,1.01)  11.4ms × (0.99,1.03)   -6.95% (p=0.000)
      Gzip                    656ms × (0.99,1.05)   647ms × (0.99,1.01)     ~    (p=0.101)
      Gunzip                  142ms × (1.00,1.00)   143ms × (1.00,1.01)   +0.58% (p=0.001)
      HTTPClientServer       91.2µs × (0.97,1.04)  88.5µs × (0.99,1.03)   -3.02% (p=0.003)
      JSONEncode             32.6ms × (0.97,1.08)  29.6ms × (0.98,1.01)   -9.10% (p=0.000)
      JSONDecode              114ms × (0.97,1.05)   104ms × (1.00,1.01)   -8.74% (p=0.000)
      Mandelbrot200          6.11ms × (0.98,1.04)  6.02ms × (1.00,1.00)     ~    (p=0.090)
      GoParse                6.66ms × (0.97,1.04)  6.37ms × (0.97,1.04)   -4.41% (p=0.000)
      RegexpMatchEasy0_32     159ns × (0.99,1.00)   152ns × (0.99,1.01)   -4.69% (p=0.000)
      RegexpMatchEasy0_1K     538ns × (1.00,1.01)   530ns × (1.00,1.00)   -1.57% (p=0.000)
      RegexpMatchEasy1_32     138ns × (1.00,1.00)   134ns × (0.99,1.01)   -2.91% (p=0.000)
      RegexpMatchEasy1_1K     869ns × (0.99,1.01)   865ns × (1.00,1.00)   -0.51% (p=0.012)
      RegexpMatchMedium_32    252ns × (0.99,1.01)   233ns × (1.00,1.00)   -7.85% (p=0.000)
      RegexpMatchMedium_1K   72.7µs × (1.00,1.00)  69.5µs × (1.00,1.00)   -4.43% (p=0.000)
      RegexpMatchHard_32     3.85µs × (1.00,1.00)  3.74µs × (1.00,1.00)   -2.74% (p=0.000)
      RegexpMatchHard_1K      118µs × (1.00,1.00)   115µs × (1.00,1.00)   -2.24% (p=0.000)
      Revcomp                 920ms × (0.97,1.07)   920ms × (0.97,1.04)     ~    (p=0.998)
      Template                129ms × (0.98,1.03)   117ms × (0.99,1.01)   -9.79% (p=0.000)
      TimeParse               619ns × (0.99,1.01)   615ns × (0.99,1.00)   -0.57% (p=0.011)
      TimeFormat              661ns × (0.98,1.04)   654ns × (0.99,1.00)     ~    (p=0.223)
      
      Change-Id: If054d81ab2c71d8d62cf54b5b1fac2af66b387fc
      Reviewed-on: https://go-review.googlesource.com/9813Reviewed-by: default avatarDavid Chase <drchase@google.com>
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      d4472799