cmd/compile: field access on struct-returning method copies entire struct

[rogpeppe]

When a method returns a struct by value and the caller only accesses a single field, the compiler copies the entire struct onto the stack even though only one field is needed. If the struct is backed by a pointer dereference, the compiler should be able to load just the accessed field directly.

This matters in practice for unique.Handle[T].Value() where T is a moderately sized struct and Value().someField is called in a hot loop.

Reproducer:

package main

type Handle[T any] struct {
	value *T
}

func (h Handle[T]) Value() T {
	return *h.value
}

type big struct {
	typ   int8
	index int64
	str   string
	pkgID string
}

type S struct {
	h Handle[big]
}

func main() { f(nil) }

var f = find

func find(ss []S) S {
	for _, s := range ss {
		if s.typ() == 2 {
			return s
		}
	}
	return S{}
}

func (s S) typ() int8 {
	if s == (S{}) {
		return 0
	}
	return s.h.Value().typ
}

With go tool objdump, the loop body for find copies the entire 40-byte big struct onto the stack (6 MOVUPS) just to read the first byte:

main.go:40   LEAQ 0(SP), SI
main.go:40   MOVUPS 0(DX), X14
main.go:40   MOVUPS X14, 0(SI)
main.go:40   MOVUPS 0x10(DX), X14
main.go:40   MOVUPS X14, 0x10(SI)
main.go:40   MOVUPS 0x20(DX), X14
main.go:40   MOVUPS X14, 0x20(SI)
main.go:40   MOVZX 0(SP), SI

Changing s.h.Value().typ to (*s.h.value).typ (an explicit pointer dereference) produces dramatically better code — a single MOVZX 0(DX), SI with no stack frame at all.

Both expressions have identical semantics when the pointer is non-nil (which is guaranteed by the nil check above), so the compiler should be able to apply this optimization.

Tested with go version go1.26.0 linux/amd64

[Dorbmon]

Benchmark results (linux/amd64, i7-14700KF)

$ go test -bench=TypVia -benchmem -count=10
BenchmarkTypViaValue-20 ~0.864 ns/op 0 B/op 0 allocs/op
BenchmarkTypViaPtr-20 ~0.401 ns/op 0 B/op 0 allocs/op

Accessing a single field via s.h.Value().typ is ~2.15× slower than (*s.h.value).typ.
In this benchmark, h.value is always non-nil, so the two expressions have identical semantics.

Benchmark code:

package main

import "testing"

type Handle[T any] struct {
    value *T
}

func (h Handle[T]) Value() T { return *h.value }

type big struct {
    typ   int8
    index int64
    str   string
    pkgID string
}

type S struct{ h Handle[big] }

var sink int8

func typViaValue(s S) int8 { return s.h.Value().typ }
func typViaPtr(s S) int8   { return (*s.h.value).typ }

func BenchmarkTypViaValue(b *testing.B) {
    backing := make([]big, 1<<15)
    ss := make([]S, len(backing))
    for i := range backing {
        backing[i].typ = int8(i)
        ss[i] = S{h: Handle[big]{value: &backing[i]}}
    }

    b.ResetTimer()
    var x int8
    for i := 0; i < b.N; i++ {
        x += typViaValue(ss[i&(len(ss)-1)])
    }
    sink = x
}

func BenchmarkTypViaPtr(b *testing.B) {
    backing := make([]big, 1<<15)
    ss := make([]S, len(backing))
    for i := range backing {
        backing[i].typ = int8(i)
        ss[i] = S{h: Handle[big]{value: &backing[i]}}
    }

    b.ResetTimer()
    var x int8
    for i := 0; i < b.N; i++ {
        x += typViaPtr(ss[i&(len(ss)-1)])
    }
    sink = x
}

[Dorbmon]

I have sent a CL to implement a generic Load <- Move forwarding rewrite with safety guards.
CL: https://go-review.googlesource.com/c/go/+/748200
This should avoid redundant struct copies in cases like s.h.Value().typ while preserving existing large-move diagnostics.

[gopherbot]

Change https://go.dev/cl/748200 mentions this issue: cmd/compile: forward small Load through Move to avoid redundant copies (issue #77720)