An error occurred fetching the project authors.
  1. 10 Mar, 2016 1 commit
  2. 09 Mar, 2016 4 commits
  3. 08 Mar, 2016 3 commits
  4. 07 Mar, 2016 3 commits
  5. 05 Mar, 2016 1 commit
  6. 04 Mar, 2016 4 commits
  7. 03 Mar, 2016 4 commits
  8. 02 Mar, 2016 3 commits
  9. 29 Feb, 2016 1 commit
  10. 27 Feb, 2016 1 commit
  11. 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
  12. 23 Feb, 2016 1 commit
  13. 22 Feb, 2016 1 commit
  14. 21 Feb, 2016 1 commit
  15. 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
  16. 15 Dec, 2015 1 commit
    • Matthew Dempsky's avatar
      cmd/compile: change dead code into assert · 22a204dd
      Matthew Dempsky authored
      After fixing #13587, I noticed that the "OAS2FUNC in disguise" block
      looked like it probably needed write barriers too.  However, testing
      revealed the multi-value "return f()" case was already being handled
      correctly.
      
      It turns out this block is dead code due to "return f()" already being
      transformed into "t1, t2, ..., tN := f(); return t1, t2, ..., tN" by
      orderstmt when f is a multi-valued function.
      
      Updates #13587.
      
      Change-Id: Icde46dccc55beda2ea5fd5fcafc9aae26cec1552
      Reviewed-on: https://go-review.googlesource.com/17759
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      22a204dd
  17. 12 Dec, 2015 1 commit
  18. 07 Dec, 2015 1 commit
  19. 12 Nov, 2015 1 commit
  20. 30 Oct, 2015 1 commit
  21. 26 Oct, 2015 1 commit
  22. 23 Oct, 2015 2 commits
  23. 21 Oct, 2015 2 commits