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: some codes in DSE rely on the order of values #70409

Open
fengyoulin opened this issue Nov 18, 2024 · 4 comments
Open

cmd/compile: some codes in DSE rely on the order of values #70409

fengyoulin opened this issue Nov 18, 2024 · 4 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@fengyoulin
Copy link
Contributor

Go version

go version devel go1.24-3ca78afb3b Mon Nov 18 04:56:52 2024 +0000 linux/amd64

Output of go env in your module/workspace:

GOAMD64='v1'
GOARCH='amd64'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOOS='linux'
GOVERSION='devel go1.24-3ca78afb3b Mon Nov 18 04:56:52 2024 +0000'

What did you do?

Compile the following code, the first time with no -gcflags, the second with -gcflags='-d=ssa/check/on', then compare the assembly code.

func foo(v uint64) (b [8]byte) {
	b[0] = byte(v)
	b[1] = byte(v >> 8)
	b[2] = byte(v >> 16)
	b[3] = byte(v >> 24)
	b[4] = byte(v >> 32)
	b[5] = byte(v >> 40)
	b[6] = byte(v >> 48)
	b[7] = byte(v >> 56)
	return b
}

What did you see happen?

The assembly code generated without -gcflags:

  foo.go:5              0x464fc0                88442408                MOVB AL, 0x8(SP)
  foo.go:6              0x464fc4                4889c1                  MOVQ AX, CX
  foo.go:6              0x464fc7                48c1e808                SHRQ $0x8, AX
  foo.go:6              0x464fcb                88442409                MOVB AL, 0x9(SP)
  foo.go:7              0x464fcf                4889c8                  MOVQ CX, AX
  foo.go:7              0x464fd2                48c1e910                SHRQ $0x10, CX
  foo.go:7              0x464fd6                884c240a                MOVB CL, 0xa(SP)
  foo.go:8              0x464fda                4889c1                  MOVQ AX, CX
  foo.go:8              0x464fdd                48c1e818                SHRQ $0x18, AX
  foo.go:8              0x464fe1                8844240b                MOVB AL, 0xb(SP)
  foo.go:9              0x464fe5                4889c8                  MOVQ CX, AX
  foo.go:9              0x464fe8                48c1e920                SHRQ $0x20, CX
  foo.go:9              0x464fec                884c240c                MOVB CL, 0xc(SP)
  foo.go:10             0x464ff0                4889c1                  MOVQ AX, CX
  foo.go:10             0x464ff3                48c1e828                SHRQ $0x28, AX
  foo.go:10             0x464ff7                8844240d                MOVB AL, 0xd(SP)
  foo.go:11             0x464ffb                4889c8                  MOVQ CX, AX
  foo.go:11             0x464ffe                48c1e930                SHRQ $0x30, CX
  foo.go:11             0x465002                884c240e                MOVB CL, 0xe(SP)
  foo.go:12             0x465006                48c1e838                SHRQ $0x38, AX
  foo.go:12             0x46500a                8844240f                MOVB AL, 0xf(SP)
  foo.go:13             0x46500e                c3                      RET

And the assembly code generated with -gcflags='-d=ssa/check/on':

  foo.go:4              0x464fc0                48c744240800000000      MOVQ $0x0, 0x8(SP) // the redundant zeroing
  foo.go:5              0x464fc9                88442408                MOVB AL, 0x8(SP)
  foo.go:6              0x464fcd                4889c1                  MOVQ AX, CX
  foo.go:6              0x464fd0                48c1e808                SHRQ $0x8, AX
  foo.go:6              0x464fd4                88442409                MOVB AL, 0x9(SP)
  foo.go:7              0x464fd8                4889c8                  MOVQ CX, AX
  foo.go:7              0x464fdb                48c1e910                SHRQ $0x10, CX
  foo.go:7              0x464fdf                884c240a                MOVB CL, 0xa(SP)
  foo.go:8              0x464fe3                4889c1                  MOVQ AX, CX
  foo.go:8              0x464fe6                48c1e818                SHRQ $0x18, AX
  foo.go:8              0x464fea                8844240b                MOVB AL, 0xb(SP)
  foo.go:9              0x464fee                4889c8                  MOVQ CX, AX
  foo.go:9              0x464ff1                48c1e920                SHRQ $0x20, CX
  foo.go:9              0x464ff5                884c240c                MOVB CL, 0xc(SP)
  foo.go:10             0x464ff9                4889c1                  MOVQ AX, CX
  foo.go:10             0x464ffc                48c1e828                SHRQ $0x28, AX
  foo.go:10             0x465000                8844240d                MOVB AL, 0xd(SP)
  foo.go:11             0x465004                4889c8                  MOVQ CX, AX
  foo.go:11             0x465007                48c1e930                SHRQ $0x30, CX
  foo.go:11             0x46500b                884c240e                MOVB CL, 0xe(SP)
  foo.go:12             0x46500f                48c1e838                SHRQ $0x38, AX
  foo.go:12             0x465013                8844240f                MOVB AL, 0xf(SP)
  foo.go:13             0x465017                c3                      RET

It seems that the redundant zeroing cannot be removed when compiling with -gcflags='-d=ssa/check/on'.

What did you expect to see?

The redundant zeroing can be removed even when compiling with -gcflags='-d=ssa/check/on'.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 18, 2024
@fengyoulin
Copy link
Contributor Author

The sample code comes from issue 47107, which should have been fixed by CL 578376, and only have the problem when compiling with -gcflags='-d=ssa/check/on'.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/629016 mentions this issue: cmd/compile: do not treat OpLocalAddr as load in DSE

@dmitshur
Copy link
Contributor

CC @golang/compiler.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 20, 2024
@dmitshur dmitshur added this to the Go1.24 milestone Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Development

No branches or pull requests

4 participants