go 在amd64架构上,将切片转换为结构体指针的unsafe转换比在386架构上生成更差的代码,

goqiplq2  于 6个月前  发布在  Go
关注(0)|答案(3)|浏览(49)

Go版本
go版本 devel go1.22-b7c630dc3a 星期二 2024年1月9日 01:36:54 +0000 linux/amd64

在你的模块/工作区中go env的输出:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/dominikh/.cache/go-build'
GOENV='/home/dominikh/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/dominikh/prj/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/dominikh/prj'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/dominikh/prj/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/dominikh/prj/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.22-b7c630dc3a Tue Jan 9 01:36:54 2024 +0000'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/dominikh/prj/src/example.com/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1255434568=/tmp/go-build -gno-record-gcc-switches'

你做了什么?

编译

package pkg

import "unsafe"

type T struct {
	A, B int
}

func Foo(x []byte) {
	Sink = (*T)(*(*unsafe.Pointer)(unsafe.Pointer(&x))).A
}

var Sink int

你看到了什么发生?

当为GOARCH=386编译时,函数体编译为

0x0012 00018 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVL    command-line-arguments.x+4(SP), AX
0x0016 00022 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVL    (AX), AX
0x0018 00024 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVL    AX, command-line-arguments.Sink(SB)

但当为GOARCH=amd64编译时,它编译为

0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:9)      MOVQ    AX, command-line-arguments.x+8(SP)
0x0005 00005 (/home/dominikh/prj/src/example.com/foo.go:9)      MOVQ    BX, command-line-arguments.x+16(SP)
0x000a 00010 (/home/dominikh/prj/src/example.com/foo.go:9)      MOVQ    CX, command-line-arguments.x+24(SP)
0x000f 00015 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVQ    command-line-arguments.x+8(SP), AX
0x0014 00020 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVQ    (AX), AX
0x0017 00023 (/home/dominikh/prj/src/example.com/foo.go:10)     MOVQ    AX, command-line-arguments.Sink(SB)

其中前4条指令是不必要的。

uwopmtnx

uwopmtnx1#

可能相关/相同的: #65192

11dmarpk

11dmarpk2#

这是regabi与旧调用约定的一个结果。
对于386,切片参数已经在栈上,所以它只需要从栈中加载所需的部分。
对于amd64,切片参数在寄存器中,因此在从它加载之前,首先需要将其溢出到栈中。
获取切片的地址会强制将其放入内存中的某个位置,因为编译器没有能力分析出实际读取了地址变量的哪些部分。
也许我们可以为这种情况做一些简单的事情。
无论如何,使用unsafe.SliceData可能是更清晰的方式来实现这一点,而且作为奖励,它可以在所有架构上生成高效的代码。

lzfw57am

lzfw57am3#

由于编译器无法分析出实际读取了地址变量的哪些部分。
实际上,这个问题在更简单(但更合成)的例子中也会出现:

func Foo(x []byte) {
	a := &x
	Sink = len(*a)
}

在这里使用SliceData可以解决问题,但不能解决在两个任意类型之间不安全地转换并访问部分字段时出现的问题。

相关问题