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.

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

cmd/compile: for small objects, use constants directly instead of copying from statictmp #21561

Closed
randall77 opened this issue Aug 22, 2017 · 5 comments

Comments

@randall77
Copy link
Contributor

func f() []int {
	return []int{7}
}

generates:

0x001d 00029 (tmp1.go:3)  LEAQ    type.[1]int(SB), AX
0x0024 00036 (tmp1.go:4)  MOVQ    AX, (SP)
0x0028 00040 (tmp1.go:4)  CALL    runtime.newobject(SB)
0x002d 00045 (tmp1.go:4)  MOVQ    8(SP), AX
0x0032 00050 (tmp1.go:4)  MOVQ    "".statictmp_0(SB), CX
0x0039 00057 (tmp1.go:4)  MOVQ    CX, (AX)

Note that the 7 is written by loading from a readonly global and writing to the slice. We should just use a

MOVQ $7, (AX)

for the last 2 lines.
Up to some small constant in size, emitting the constants explicitly instead of copying them from a statictmp is better.

@randall77 randall77 added this to the Go1.10 milestone Aug 22, 2017
@josharian
Copy link
Contributor

We do this a few places already. IIRC, the cutoff we have used for "up to some small constant in size" is whether it is SSA-able.

@gopherbot
Copy link

Change https://golang.org/cl/197560 mentions this issue: cmd/compile: don't use statictmps for small object constant in slice literal

@gopherbot
Copy link

Change https://golang.org/cl/199280 mentions this issue: internal/reflectlite: add type mirror with reflect test

@cuonglm
Copy link
Member

cuonglm commented Oct 5, 2019

Change https://golang.org/cl/199280 mentions this issue: internal/reflectlite: add type mirror with reflect test

Ops, this is wrong reference.

@gopherbot
Copy link

Change https://golang.org/cl/199558 mentions this issue: cmd/compile: improve write barrier removal

gopherbot pushed a commit that referenced this issue Oct 7, 2019
We're allowed to remove a write barrier when both the old
value in memory and the new value we're writing are not heap pointers.

Improve both those checks a little bit.

A pointer is known to not be a heap pointer if it is read from
read-only memory. This sometimes happens for loads of pointers
from string constants in read-only memory.

Do a better job of tracking which parts of memory are known to be
zero.  Before we just kept track of a range of offsets in the most
recently allocated object. For code that initializes the new object's
fields in a nonstandard order, that tracking is imprecise. Instead,
keep a bit map of the first 64 words of that object, so we can track
precisely what we know to be zeroed.

The new scheme is only precise up to the first 512 bytes of the object.
After that, we'll use write barriers unnecessarily. Hopefully most
initializers of large objects will use typedmemmove, which does only one
write barrier check for the whole initialization.

Fixes #34723
Update #21561

Change-Id: Idf6e1b7d525042fb67961302d4fc6f941393cac8
Reviewed-on: https://go-review.googlesource.com/c/go/+/199558
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
@golang golang locked and limited conversation to collaborators Oct 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants