An error occurred fetching the project authors.
  1. 14 Mar, 2017 1 commit
  2. 08 Mar, 2017 1 commit
    • David Chase's avatar
      cmd/compile: check loop rescheduling with stack bound, not counter · d71f36b5
      David Chase authored
      After benchmarking with a compiler modified to have better
      spill location, it became clear that this method of checking
      was actually faster on (at least) two different architectures
      (ppc64 and amd64) and it also provides more timely interruption
      of loops.
      
      This change adds a modified FOR loop node "FORUNTIL" that
      checks after executing the loop body instead of before (i.e.,
      always at least once).  This ensures that a pointer past the
      end of a slice or array is not made visible to the garbage
      collector.
      
      Without the rescheduling checks inserted, the restructured
      loop from this  change apparently provides a 1% geomean
      improvement on PPC64 running the go1 benchmarks; the
      improvement on AMD64 is only 0.12%.
      
      Inserting the rescheduling check exposed some peculiar bug
      with the ssa test code for s390x; this was updated based on
      initial code actually generated for GOARCH=s390x to use
      appropriate OpArg, OpAddr, and OpVarDef.
      
      NaCl is disabled in testing.
      
      Change-Id: Ieafaa9a61d2a583ad00968110ef3e7a441abca50
      Reviewed-on: https://go-review.googlesource.com/36206
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      d71f36b5
  3. 03 Mar, 2017 1 commit
    • Aliaksandr Valialkin's avatar
      cmd/compile: pack bool fields in Node, Name, Func and Type structs to bitsets · ed70f37e
      Aliaksandr Valialkin authored
      This reduces compiler memory usage by up to 4% - see compilebench
      results below.
      
      name       old time/op     new time/op     delta
      Template       245ms ± 4%      241ms ± 2%  -1.88%  (p=0.029 n=10+10)
      Unicode        126ms ± 3%      124ms ± 3%    ~     (p=0.105 n=10+10)
      GoTypes        805ms ± 2%      813ms ± 3%    ~     (p=0.515 n=8+10)
      Compiler       3.95s ± 2%      3.83s ± 1%  -2.96%  (p=0.000 n=9+10)
      MakeBash       47.4s ± 4%      46.6s ± 1%  -1.59%  (p=0.028 n=9+10)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        324M ± 5%       326M ± 3%    ~     (p=0.935 n=10+10)
      Unicode         186M ± 5%       178M ±10%    ~     (p=0.067 n=9+10)
      GoTypes        1.08G ± 7%      1.09G ± 4%    ~     (p=0.956 n=10+10)
      Compiler       5.34G ± 4%      5.31G ± 1%    ~     (p=0.501 n=10+8)
      
      name       old alloc/op    new alloc/op    delta
      Template      41.0MB ± 0%     39.8MB ± 0%  -3.03%  (p=0.000 n=10+10)
      Unicode       32.3MB ± 0%     31.0MB ± 0%  -4.13%  (p=0.000 n=10+10)
      GoTypes        119MB ± 0%      116MB ± 0%  -2.39%  (p=0.000 n=10+10)
      Compiler       499MB ± 0%      487MB ± 0%  -2.48%  (p=0.000 n=10+10)
      
      name       old allocs/op   new allocs/op   delta
      Template        380k ± 1%       379k ± 1%    ~     (p=0.436 n=10+10)
      Unicode         324k ± 1%       324k ± 0%    ~     (p=0.853 n=10+10)
      GoTypes        1.15M ± 0%      1.15M ± 0%    ~     (p=0.481 n=10+10)
      Compiler       4.41M ± 0%      4.41M ± 0%  -0.12%  (p=0.007 n=10+10)
      
      name       old text-bytes  new text-bytes  delta
      HelloSize       623k ± 0%       623k ± 0%    ~     (all equal)
      CmdGoSize      6.64M ± 0%      6.64M ± 0%    ~     (all equal)
      
      name       old data-bytes  new data-bytes  delta
      HelloSize      5.81k ± 0%      5.81k ± 0%    ~     (all equal)
      CmdGoSize       238k ± 0%       238k ± 0%    ~     (all equal)
      
      name       old bss-bytes   new bss-bytes   delta
      HelloSize       134k ± 0%       134k ± 0%    ~     (all equal)
      CmdGoSize       152k ± 0%       152k ± 0%    ~     (all equal)
      
      name       old exe-bytes   new exe-bytes   delta
      HelloSize       967k ± 0%       967k ± 0%    ~     (all equal)
      CmdGoSize      10.2M ± 0%      10.2M ± 0%    ~     (all equal)
      
      Change-Id: I1f40af738254892bd6c8ba2eb43390b175753d52
      Reviewed-on: https://go-review.googlesource.com/37445Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      ed70f37e
  4. 27 Feb, 2017 1 commit
    • Josh Bleecher Snyder's avatar
      cmd/compile: ignore some dead code during escape analysis · 1e29cd8c
      Josh Bleecher Snyder authored
      This is the escape analysis analog of CL 37499.
      
      Fixes #12397
      Fixes #16871
      
      The only "moved to heap" decisions eliminated by this
      CL in std+cmd are:
      
      cmd/compile/internal/gc/const.go:1514: moved to heap: ac
      cmd/compile/internal/gc/const.go:1515: moved to heap: bd
      cmd/compile/internal/gc/const.go:1516: moved to heap: bc
      cmd/compile/internal/gc/const.go:1517: moved to heap: ad
      cmd/compile/internal/gc/const.go:1546: moved to heap: ac
      cmd/compile/internal/gc/const.go:1547: moved to heap: bd
      cmd/compile/internal/gc/const.go:1548: moved to heap: bc
      cmd/compile/internal/gc/const.go:1549: moved to heap: ad
      cmd/compile/internal/gc/const.go:1550: moved to heap: cc_plus
      cmd/compile/internal/gc/export.go:162: moved to heap: copy
      cmd/compile/internal/gc/mpfloat.go:66: moved to heap: b
      cmd/compile/internal/gc/mpfloat.go:97: moved to heap: b
      
      Change-Id: I0d420b69c84a41ba9968c394e8957910bab5edea
      Reviewed-on: https://go-review.googlesource.com/37508Reviewed-by: default avatarDavid Chase <drchase@google.com>
      1e29cd8c
  5. 10 Feb, 2017 1 commit
  6. 08 Dec, 2016 1 commit
  7. 27 Oct, 2016 4 commits
    • Matthew Dempsky's avatar
      cmd/compile: stop adding implicit OKEY nodes · bba1ac4f
      Matthew Dempsky authored
      Keys are uncommon in array and slice literals, and normalizing
      OARRAYLIT and OSLICELIT nodes to always use OKEY ends up not reducing
      complexity much. Instead, only create OKEY nodes to represent explicit
      keys, and recalculate implicit keys when/where necessary.
      
      Fixes #15350.
      
      name       old time/op     new time/op     delta
      Template       299ms ± 9%      299ms ±12%    ~           (p=0.694 n=28+30)
      Unicode        165ms ± 7%      162ms ± 9%    ~           (p=0.084 n=27+27)
      GoTypes        950ms ± 9%      963ms ± 5%    ~           (p=0.301 n=30+29)
      Compiler       4.23s ± 7%      4.17s ± 7%    ~           (p=0.057 n=29+27)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        389M ±15%       400M ±12%    ~           (p=0.202 n=30+29)
      Unicode         246M ±21%       232M ±22%  -5.76%        (p=0.006 n=28+29)
      GoTypes        1.34G ± 8%      1.34G ± 7%    ~           (p=0.775 n=28+30)
      Compiler       5.91G ± 6%      5.87G ± 7%    ~           (p=0.298 n=28+29)
      
      name       old alloc/op    new alloc/op    delta
      Template      41.2MB ± 0%     41.2MB ± 0%    ~           (p=0.085 n=30+30)
      Unicode       34.0MB ± 0%     31.5MB ± 0%  -7.28%        (p=0.000 n=30+29)
      GoTypes        121MB ± 0%      121MB ± 0%    ~           (p=0.657 n=30+30)
      Compiler       511MB ± 0%      511MB ± 0%  -0.01%        (p=0.001 n=29+29)
      
      name       old allocs/op   new allocs/op   delta
      Template        390k ± 0%       390k ± 0%    ~           (p=0.225 n=30+29)
      Unicode         318k ± 0%       293k ± 0%  -8.03%        (p=0.000 n=30+29)
      GoTypes        1.16M ± 0%      1.16M ± 0%    ~           (p=0.745 n=30+30)
      Compiler       4.35M ± 0%      4.35M ± 0%    ~           (p=0.105 n=30+30)
      
      Change-Id: I6310739a0bfdb54f1ab8a460b2c03615ad1ff5bc
      Reviewed-on: https://go-review.googlesource.com/32221Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bba1ac4f
    • Josh Bleecher Snyder's avatar
      cmd/compile: change Func.FCurfn to IsHiddenClosure · dc53ea77
      Josh Bleecher Snyder authored
      IsHiddenClosure is more descriptive.
      
      Change-Id: I06651072925a958b148b64ab0db3a9bfc839af9b
      Reviewed-on: https://go-review.googlesource.com/32224
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      dc53ea77
    • Josh Bleecher Snyder's avatar
      cmd/compile: remove Label type · a7c84668
      Josh Bleecher Snyder authored
      With the removal of the old backend,
      a Label is just a Node.
      
      Passes toolstash -cmp.
      
      Change-Id: Ia62cb00fbc551efb75a4ed4dc6ed54fca0831dbf
      Reviewed-on: https://go-review.googlesource.com/32216
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      a7c84668
    • Hiroshi Ioka's avatar
      cmd/compile/internal/gc: remove EscScope · f8a34443
      Hiroshi Ioka authored
      EscScope behaves like EscHeap in current code.
      There are no need to handle it specially.
      So remove it and use EscHeap instead.
      
      Change-Id: I910106fd147f00e5f4fd52c7dde05128141a5160
      Reviewed-on: https://go-review.googlesource.com/32130
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      f8a34443
  8. 26 Oct, 2016 1 commit
    • David Chase's avatar
      cmd/compile: add explicit 'where' to EscStep data for explanations · bea5252a
      David Chase authored
      Sometimes neither the src nor the dst of an escape edge
      contains the line number appropriate to the edge, so add
      a field so that can be set correctly.
      
      Also updated some of the explanations to be less jargon-y
      and perhaps more informative, and folded bug example into
      test.
      
      Cleaned up some of the function/method names in esc.go
      and did a quick sanity check that each "bundling" function
      was actually called often enough to justify its existence.
      
      Fixes #17459.
      
      Change-Id: Ieba53ab0a6ba1f7a6c4962bc0b702ede9cc3a3cc
      Reviewed-on: https://go-review.googlesource.com/31660
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      bea5252a
  9. 13 Oct, 2016 2 commits
    • Matthew Dempsky's avatar
      cmd/compile: add OSTRUCTKEY for keyed struct literals · add3ff54
      Matthew Dempsky authored
      Previously, we used OKEY nodes to represent keyed struct literal
      elements. The field names were represented by an ONAME node, but this
      is clumsy because it's the only remaining case where ONAME was used to
      represent a bare identifier and not a variable.
      
      This CL introduces a new OSTRUCTKEY node op for use in struct
      literals. These ops instead store the field name in the node's own Sym
      field. This is similar in spirit to golang.org/cl/20890.
      
      Significant reduction in allocations for struct literal heavy code
      like package unicode:
      
      name       old time/op     new time/op     delta
      Template       345ms ± 6%      341ms ± 6%     ~           (p=0.141 n=29+28)
      Unicode        200ms ± 9%      184ms ± 7%   -7.77%        (p=0.000 n=29+30)
      GoTypes        1.04s ± 3%      1.05s ± 3%     ~           (p=0.096 n=30+30)
      Compiler       4.47s ± 9%      4.49s ± 6%     ~           (p=0.890 n=29+29)
      
      name       old user-ns/op  new user-ns/op  delta
      Template        523M ±13%       516M ±17%     ~           (p=0.400 n=29+30)
      Unicode         334M ±27%       314M ±30%     ~           (p=0.093 n=30+30)
      GoTypes        1.53G ±10%      1.52G ±10%     ~           (p=0.572 n=30+30)
      Compiler       6.28G ± 7%      6.34G ±11%     ~           (p=0.300 n=30+30)
      
      name       old alloc/op    new alloc/op    delta
      Template      44.5MB ± 0%     44.4MB ± 0%   -0.35%        (p=0.000 n=27+30)
      Unicode       39.2MB ± 0%     34.5MB ± 0%  -11.79%        (p=0.000 n=26+30)
      GoTypes        125MB ± 0%      125MB ± 0%   -0.12%        (p=0.000 n=29+30)
      Compiler       515MB ± 0%      515MB ± 0%   -0.10%        (p=0.000 n=29+30)
      
      name       old allocs/op   new allocs/op   delta
      Template        426k ± 0%       424k ± 0%   -0.39%        (p=0.000 n=29+30)
      Unicode         374k ± 0%       323k ± 0%  -13.67%        (p=0.000 n=29+30)
      GoTypes        1.21M ± 0%      1.21M ± 0%   -0.14%        (p=0.000 n=29+29)
      Compiler       4.40M ± 0%      4.39M ± 0%   -0.13%        (p=0.000 n=29+30)
      
      Passes toolstash/buildall.
      
      Change-Id: Iba4ee765dd1748f67e52fcade1cd75c9f6e13fa9
      Reviewed-on: https://go-review.googlesource.com/30974
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      add3ff54
    • Hiroshi Ioka's avatar
      cmd/compile/internal/gc: cleanup esc.go · 0a0f4bc1
      Hiroshi Ioka authored
      * convert important functions to methods
      * rename EscXXX to XXX in NodeEscState
      * rename local variables more friendly
      * simplify redundant code
      * update comments
      
      Change-Id: I8442bf4f8dde84523d9a2ad3d04b1cd326bd4719
      Reviewed-on: https://go-review.googlesource.com/30893
      Run-TryBot: David Chase <drchase@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      0a0f4bc1
  10. 11 Oct, 2016 1 commit
  11. 10 Oct, 2016 1 commit
  12. 27 Sep, 2016 1 commit
  13. 16 Sep, 2016 1 commit
  14. 15 Sep, 2016 2 commits
  15. 12 Sep, 2016 1 commit
  16. 08 Sep, 2016 2 commits
  17. 07 Sep, 2016 3 commits
  18. 04 Sep, 2016 1 commit
  19. 06 Jul, 2016 1 commit
    • Ian Lance Taylor's avatar
      cmd/compile, syscall: add //go:uintptrescapes comment, and use it · bbe5da42
      Ian Lance Taylor authored
      This new comment can be used to declare that the uintptr arguments to a
      function may be converted from pointers, and that those pointers should
      be considered to escape. This is used for the Call methods in
      dll_windows.go that take uintptr arguments, because they call Syscall.
      
      We can't treat these functions as we do syscall.Syscall, because unlike
      Syscall they may cause the stack to grow. For Syscall we can assume that
      stack arguments can remain on the stack, but for these functions we need
      them to escape.
      
      Fixes #16035.
      
      Change-Id: Ia0e5b4068c04f8d303d95ab9ea394939f1f57454
      Reviewed-on: https://go-review.googlesource.com/24551Reviewed-by: default avatarDavid Chase <drchase@google.com>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bbe5da42
  20. 27 May, 2016 3 commits
    • Russ Cox's avatar
      cmd/compile: clean up, document Node closure fields · 36a80c59
      Russ Cox authored
      Requested during CL 23431.
      
      Change-Id: I513ae42166b3a9fcfe51231ff55c163ab672e7d2
      Reviewed-on: https://go-review.googlesource.com/23485Reviewed-by: default avatarDavid Chase <drchase@google.com>
      36a80c59
    • Russ Cox's avatar
      cmd/compile: eliminate PPARAMREF · 20803b84
      Russ Cox authored
      As in the elimination of PHEAP|PPARAM in CL 23393,
      this is something the front end can trivially take care of
      and then not bother the back ends with.
      It also eliminates some suspect (and only lightly exercised)
      code paths in the back ends.
      
      I don't have a smoking gun for this one but it seems
      more clearly correct.
      
      Change-Id: I3b3f5e669b3b81d091ff1e2fb13226a6f14c69d5
      Reviewed-on: https://go-review.googlesource.com/23431Reviewed-by: default avatarKeith Randall <khr@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      20803b84
    • Russ Cox's avatar
      cmd/compile: fix liveness computation for heap-escaped parameters · b6dc3e6f
      Russ Cox authored
      The liveness computation of parameters generally was never
      correct, but forcing all parameters to be live throughout the
      function covered up that problem. The new SSA back end is
      too clever: even though it currently keeps the parameter values live
      throughout the function, it may find optimizations that mean
      the current values are not written back to the original parameter
      stack slots immediately or ever (for example if a parameter is set
      to nil, SSA constant propagation may replace all later uses of the
      parameter with a constant nil, eliminating the need to write the nil
      value back to the stack slot), so the liveness code must now
      track the actual operations on the stack slots, exposing these
      problems.
      
      One small problem in the handling of arguments is that nodarg
      can return ONAME PPARAM nodes with adjusted offsets, so that
      there are actually multiple *Node pointers for the same parameter
      in the instruction stream. This might be possible to correct, but
      not in this CL. For now, we fix this by using n.Orig instead of n
      when considering PPARAM and PPARAMOUT nodes.
      
      The major problem in the handling of arguments is general
      confusion in the liveness code about the meaning of PPARAM|PHEAP
      and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP.
      The difference between these two is that when a local variable "moves"
      to the heap, it's really just allocated there to start with; in contrast,
      when an argument moves to the heap, the actual data has to be copied
      there from the stack at the beginning of the function, and when a
      result "moves" to the heap the value in the heap has to be copied
      back to the stack when the function returns
      This general confusion is also present in the SSA back end.
      
      The PHEAP bit worked decently when I first introduced it 7 years ago (!)
      in 391425ae. The back end did nothing sophisticated, and in particular
      there was no analysis at all: no escape analysis, no liveness analysis,
      and certainly no SSA back end. But the complications caused in the
      various downstream consumers suggest that this should be a detail
      kept mainly in the front end.
      
      This CL therefore eliminates both the PHEAP bit and even the idea of
      "heap variables" from the back ends.
      
      First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP
      variable classes with the single PAUTOHEAP, a pseudo-class indicating
      a variable maintained on the heap and available by indirecting a
      local variable kept on the stack (a plain PAUTO).
      
      Second, walkexpr replaces all references to PAUTOHEAP variables
      with indirections of the corresponding PAUTO variable.
      The back ends and the liveness code now just see plain indirected
      variables. This may actually produce better code, but the real goal
      here is to eliminate these little-used and somewhat suspect code
      paths in the back end analyses.
      
      The OPARAM node type goes away too.
      
      A followup CL will do the same to PPARAMREF. I'm not sure that
      the back ends (SSA in particular) are handling those right either,
      and with the framework established in this CL that change is trivial
      and the result clearly more correct.
      
      Fixes #15747.
      
      Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74
      Reviewed-on: https://go-review.googlesource.com/23393Reviewed-by: default avatarKeith Randall <khr@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      b6dc3e6f
  21. 19 May, 2016 1 commit
  22. 28 Apr, 2016 1 commit
  23. 27 Apr, 2016 2 commits
  24. 25 Apr, 2016 2 commits
  25. 06 Apr, 2016 1 commit
  26. 05 Apr, 2016 1 commit
  27. 01 Apr, 2016 1 commit
  28. 30 Mar, 2016 1 commit