Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/compile: &T{} clears the memory twice. #15199

Closed
OneOfOne opened this issue Apr 8, 2016 · 2 comments
Closed

cmd/compile: &T{} clears the memory twice. #15199

OneOfOne opened this issue Apr 8, 2016 · 2 comments
Labels
FrozenDueToAge Performance
Milestone
Go1.8

Comments

@OneOfOne
Copy link
Contributor

OneOfOne commented Apr 8, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go version devel +6c5352f 2016-04-08 18:40:11 +0000 linux/amd64
  2. What operating system and processor architecture are you using (go env)?
  3. What did you do?
type C struct { a, b, c, d, e uint64 }

func New() *C { return &C{} }
  1. What did you expect to see?
0x001e 00030 (blah.go:8)        CALL    runtime.newobject(SB)
0x0023 00035 (blah.go:8)        MOVQ    8(SP), CX
0x0028 00040 (blah.go:8)        MOVQ    CX, "".~r0+24(FP)
  1. What did you see instead?
0x001e 00030 (blah.go:8)        CALL    runtime.newobject(SB)
0x0023 00035 (blah.go:8)        MOVQ    8(SP), CX
0x0028 00040 (blah.go:8)        MOVQ    $0, (CX)
0x002f 00047 (blah.go:8)        MOVQ    $0, 8(CX)
0x0037 00055 (blah.go:8)        MOVQ    $0, 16(CX)
0x003f 00063 (blah.go:8)        MOVQ    $0, 24(CX)
0x0047 00071 (blah.go:8)        MOVQ    $0, 32(CX)
0x004f 00079 (blah.go:8)        MOVQ    CX, "".~r0+24(FP)

runtime.newobject() already calls memclr as far as I can tell, shouldn't that be enough or am I misreading it?
@dr2chase
Copy link
Contributor

dr2chase commented Apr 8, 2016

The pattern to match is kinda ugly, since you need to know that the call to runtime.newobject, followed by OffPtr <**C> [8] v2, yields pre-zeroed memory. Also a non-nil pointer.

b1:
v1 = InitMem <mem>
v2 = SP <uintptr>
v3 = SB <uintptr>
v6 = Addr <*uint8> {type."".C} v3
v7 = OffPtr <**byte> v2
v8 = Store <mem> [8] v7 v6 v1
v9 = StaticCall <mem> [16] {runtime.newobject} v8
v10 = OffPtr <**C> [8] v2
Call v9 → b2
b2: ← b1
v12 = Load <*C> v10 v9
v13 = NilCheck <void> v12 v9
Check v13 → b3
b3: ← b2
v15 = Zero <mem> [40] v12 v9
v17 = Addr <**C> {~r0} v2
v18 = VarDef <mem> {~r0} v15
v19 = Store <mem> [8] v17 v12 v18
Ret v19

@bradfitz bradfitz added this to the Unplanned milestone Apr 9, 2016
@ghost ghost mentioned this issue Apr 20, 2016
Closed
@randall77 randall77 modified the milestones: Go1.8, Unplanned Apr 20, 2016
@freeformz freeformz mentioned this issue Jul 25, 2016
Closed
@randall77
Copy link
Contributor

Fixed, duplicate of #15914

@golang golang locked and limited conversation to collaborators Aug 31, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Performance
Projects
None yet
Milestone
Go1.8
Development

No branches or pull requests
5 participants
@bradfitz @OneOfOne @dr2chase @randall77 @gopherbot