cmd/compile/internal/walk: expand the number of cases where the makeslicecopy function is generated.

55 views
Skip to first unread message

Oleg Aleksandrov

unread,
Jul 22, 2026, 12:06:00 PM (21 hours ago) Jul 22
to golang-dev
Hello,
I've been experimenting with generating the makeslicecopy function at the IR stage of the Go compiler. Generation for this function already exists (link to CL), but it 
is currently limited to cases where both dst and src are simple ir.Name nodes. My experiment extends this to handle more complex left-hand side expressions (such as pointer dereferencing, struct field access, and array indexing) without function calls.

To ensure correctness in these new cases, I am using ir.SameSafeExpr() to verify that src doesn't alias dst. Is this check sufficient, or are there aliasing scenarios it might miss? My change passes all tests of the Go compiler, but I would still appreciate confirmation that my approach is sound.

Finally, could you suggest which benchmarks I should use to evaluate the real-world performance of this change, beyond synthetic microbenchmarks?

Keith Randall

unread,
Jul 22, 2026, 7:16:15 PM (14 hours ago) Jul 22
to Oleg Aleksandrov, golang-dev
The generic answer is that you can assume SameSafeExpr does what its spec says, and nothing more.
The intent of that function is for code like

a, b := someExpression1, someExpression2

if SameSafeExpr(someExpression1, someExpression2) == true, then you can instead do
a := someExpression1
b := a

I don't think that says anything about aliasing. For instance, SameSafeExpr(a, a) == true. For something like:

a := []byte{3,4,5}
a = make([]byte, 5)
copy(a, a)

then you can't use the original value of `a` as the argument to makeslicecopy.

(The aliasing part in SameSafeExpr's spec is about the fact that a, b := make([]byte, 5), make([]byte, 5) must still make 2 byte slices.)

As far as benchmarks, a microbenchmark is fine to use for this case. But I'd also like a few references to where it actually triggers in real code. Not a benchmark per se, but some realistic code that would be helped by the optimization.



--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-dev/8a5b4754-f826-46e2-8948-446bc0636b7bn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages