Skip to content

G
golang
Switch branch/tag
  1. 18 Jul, 2016 3 commits
  3. 16 Jul, 2016 2 commits
  5. 15 Jul, 2016 3 commits
    • Cherry Zhang's avatar
      [dev.ssa] cmd/compile: fix argument size of runtime call in SSA for ARM · 6adb97bd
      Cherry Zhang authored 
      The argument size for runtime call was incorrectly includes the size
of LR (FixedFrameSize in general). This makes the stack frame
sometimes unnecessarily 4 bytes larger on ARM.
For example,
	func f(b []byte) byte { return b[0] }
compiles to
	0x0000 00000 (h.go:6)	TEXT	"".f(SB), $4-16 // <-- framesize = 4
	0x0000 00000 (h.go:6)	MOVW	8(g), R1
	0x0004 00004 (h.go:6)	CMP	R1, R13
	0x0008 00008 (h.go:6)	BLS	52
	0x000c 00012 (h.go:6)	MOVW.W	R14, -8(R13)
	0x0010 00016 (h.go:6)	FUNCDATA	$0, gclocals·8355ad952265fec823c17fcf739bd009(SB)
	0x0010 00016 (h.go:6)	FUNCDATA	$1, gclocals·69c1753bd5f81501d95132d08af04464(SB)
	0x0010 00016 (h.go:6)	MOVW	"".b+4(FP), R0
	0x0014 00020 (h.go:6)	CMP	$0, R0
	0x0018 00024 (h.go:6)	BLS	44
	0x001c 00028 (h.go:6)	MOVW	"".b(FP), R0
	0x0020 00032 (h.go:6)	MOVBU	(R0), R0
	0x0024 00036 (h.go:6)	MOVB	R0, "".~r1+12(FP)
	0x0028 00040 (h.go:6)	MOVW.P	8(R13), R15
	0x002c 00044 (h.go:6)	PCDATA	$0, $1
	0x002c 00044 (h.go:6)	CALL	runtime.panicindex(SB)
	0x0030 00048 (h.go:6)	UNDEF
	0x0034 00052 (h.go:6)	NOP
	0x0034 00052 (h.go:6)	MOVW	R14, R3
	0x0038 00056 (h.go:6)	CALL	runtime.morestack_noctxt(SB)
	0x003c 00060 (h.go:6)	JMP	0

Note that the frame size is 4, but there is actually no local. It
incorrectly thinks call to runtime.panicindex needs 4 bytes space
for argument.

This CL fixes it.

Updates #15365.

Change-Id: Ic65d55283a6aa8a7861d7a3fbc7b63c35785eeec
Reviewed-on: https://go-review.googlesource.com/24909
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      6adb97bd
    • Cherry Zhang's avatar
      [dev.ssa] cmd/compile: don't sink spills that satisfy merge edges in SSA · 7bd88a65
      Cherry Zhang authored 
      If a spill is used to satisfy a merge edge (in shuffle), don't sink
it out of loop.

This is found in the following code (on ARM) where there is a stack
Phi (v268) inside a loop (b36 -> ... -> b47 -> b38 -> b36).

(before shuffle)
  b36: <- b34 b38
    ...
    v268 = Phi <int> v410 v360 : autotmp_198[int]
    ...
    ... -> b47
  b47: <- b44
    ...
    v360 = ... : R6
    v230 = StoreReg <int> v360 : autotmp_198[int]
    v261 = CMPconst <flags> [0] v360
    EQ v261 -> b49 b38 (unlikely)
  b38: <- b47
    ...
    Plain -> b36

During shuffle, v230 (as spill of v360) is found to satisfy v268, but
it didn't record its use in shuffle, and v230 is sunk out of the loop
(to b49), which leads to bad value in v268.

This seems never happened on AMD64 (in make.bash), until 4 registers
are removed.

Change-Id: I01dfc28ae461e853b36977c58bcfc0669e556660
Reviewed-on: https://go-review.googlesource.com/24858Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      7bd88a65
    • Cherry Zhang's avatar
      [dev.ssa] cmd/compile: use shifted and indexed ops in SSA for ARM · 8cc3f4a1
      Cherry Zhang authored 
      This CL implements the following optimizations for ARM:
- use shifted ops (e.g. ADD R1<<2, R2) and indexed load/stores
- break up shift ops. Shifts used to be one SSA op that generates
  multiple instructions. We break them up to multiple ops, which
  allows constant folding and CSE for comparisons. Conditional moves
  are introduced for this.
- simplify zero/sign-extension ops.

Updates #15365.

Change-Id: I55e262a776a7ef2a1505d75e04d1208913c35d39
Reviewed-on: https://go-review.googlesource.com/24512
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      8cc3f4a1
  7. 13 Jul, 2016 4 commits
  9. 12 Jul, 2016 4 commits
  11. 11 Jul, 2016 5 commits
  13. 08 Jul, 2016 5 commits
  15. 07 Jul, 2016 3 commits
  17. 06 Jul, 2016 6 commits
  19. 05 Jul, 2016 1 commit
    • Emmanuel Odeke's avatar
      encoding/gob: document Encode, EncodeValue nil pointer panics · 5a9d5c37
      Emmanuel Odeke authored 
      Fixes #16258.

Docs for Encode and EncodeValue do not mention that
nil pointers are not permitted hence we panic,
because Gobs encode values yet nil pointers have no value
to encode. It moves a comment that was internal to EncodeValue
to the top level to make it clearer to users what to expect
when they pass in nil pointers.
Supplements test TestTopLevelNilPointer.

Change-Id: Ie54f609fde4b791605960e088456047eb9aa8738
Reviewed-on: https://go-review.googlesource.com/24740Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      5a9d5c37
  21. 04 Jul, 2016 4 commits