This doesn't need to be a proposal - it seems like an instance where the compiler could do a better job.

cc @randall77

The compiler already does the optimization you're requesting:

type Example struct {
  a, b int32
}
func f(x, y *Example) {
	*x = *y
}

compiles to 2 MOVQs, at least on amd64. If you're seeing something different, can you please post a complete compilable example that shows the problem?

There is also the semantics question:

it confuse me about the memory behavior, assume we have one routine write x=Example{x:1, y:1} and another write x=Example{x:2, y:2}, according to the memory model, x will either be x:1,y:1 or x:2, y:2.

I don't think it is mentioned in the memory model spec, but each field of a struct is its own variable. The Go spec hints at that:

Structured variables of array, slice, and struct types have elements and fields that may be addressed individually. Each such element acts like a variable.

As a result, the memory model does not forbid a result of x:1,y:2 or x:2,y:1. In other words, struct reads and writes are not atomic. If you want to avoid tearing of a 64-bit value, you need to use a 64-bit type, not a struct with 2 32-bit fields.

The compiler already does the optimization you're requesting:

type Example struct {
  a, b int32
}
func f(x, y *Example) {
	*x = *y
}

compiles to 2 MOVQs, at least on amd64. If you're seeing something different, can you please post a complete compilable example that shows the problem?

There is also the semantics question:

it confuse me about the memory behavior, assume we have one routine write x=Example{x:1, y:1} and another write x=Example{x:2, y:2}, according to the memory model, x will either be x:1,y:1 or x:2, y:2.

I don't think it is mentioned in the memory model spec, but each field of a struct is its own variable. The Go spec hints at that:

Structured variables of array, slice, and struct types have elements and fields that may be addressed individually. Each such element acts like a variable.

As a result, the memory model does not forbid a result of x:1,y:2 or x:2,y:1. In other words, struct reads and writes are not atomic. If you want to avoid tearing of a 64-bit value, you need to use a 64-bit type, not a struct with 2 32-bit fields.

yes, it's true that write a struct of two variable are not atomic. it confuse me that write value to struct(a := Example{...}) and copy value to struct(a:= b) behave not same.

code below:

1: package main
2: 
3: import "fmt"
4:
5: type Example struct {
6: 	x, y int32
7: }
8: 
9: func main() {
10:	var a = Example{x: 1, y: 2}
11:	go func() {
12:		a = Example{x: 2, y: 1}
13:	}()
14:	b := a
15:	fmt.Println(b)
16:}

will be compile to

// const init is movq
 0x0020 00032 (ff.go:10) CALL    runtime.newobject(SB)
 0x0025 00037 (ff.go:10) MOVQ    AX, "".&a+48(SP)
 0x002a 00042 (ff.go:10) MOVQ    $8589934593, CX
 0x0034 00052 (ff.go:10) MOVQ    CX, (AX)

// const init is movq
0x0004 00004 (ff.go:12) MOVQ    $4294967298, CX
0x000e 00014 (ff.go:12) MOVQ    CX, (AX)

// assign is two movl
0x0076 00118 (ff.go:14) MOVQ    "".&a+48(SP), CX
0x007b 00123 (ff.go:14) MOVL    (CX), DX
0x007d 00125 (ff.go:14) MOVL    4(CX), CX

go env:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go1.18/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3818297273=/tmp/go-build -gno-record-gcc-switches"

Ah, ok. Here's a simpler reproducer, using 2 loads/stores instead of one.

package main

type Example struct {
	x, y int32
}

func f(p *Example) interface{} {
	x := *p
	return x
}

I think a vardef for the temporary used to pass into convTnoptr is getting in the way of the combining rule.

Change https://go.dev/cl/419320 mentions this issue: cmd/compile: issue VarDef only for pointer-ful types