cmd/compile: runtime.growslice optimization does not work with named slice types

[dsnet]

Using 558785a

Consider the following benchmark:

var s []byte
var n = 100

func BenchmarkConcrete(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		s = nil
		bytesExtend(s, n)
	}
}
func bytesExtend(s []byte, n int) []byte {
	return append(s[:cap(s)], make([]byte, n)...)[:len(s)]
}

func BenchmarkGeneric(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		s = nil
		genericExtend(s, n)
	}
}
func genericExtend[S ~[]E, E any](s S, n int) S {
	return append(s[:cap(s)], make(S, n)...)[:len(s)]
}

Running these produces:

BenchmarkConcrete-24    	35770728	        33.78 ns/op	     112 B/op	       1 allocs/op
BenchmarkGeneric-24     	18596673	        63.85 ns/op	     224 B/op	       2 allocs/op

There's an additional allocation in BenchmarkGeneric over BenchmarkConcrete,
even though the benchmarks are semantically equivalent where bytesExtend is identical to genericExtend[[]byte].
The compiled logic for genericExtend[[]byte] contains a call to runtime.makeslice that does not exist in bytesExtend.

\cc @randall77

[dsnet]

This bug affects slices.Grow such that growing always allocates twice.

\cc @ianlancetaylor

[mknyszek]

@dsnet Which versions of Go does this affect?

[dsnet]

Go1.18.4 up to and including HEAD (go1.19-558785a0a9)

[dsnet]

Interesting. This benchmark only allocates once as expected:

func BenchmarkGeneric2(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		s = nil
		genericExtend2(s, n)
	}
}
func genericExtend2[T any](s []T, n int) []T {
	return append(s[:cap(s)], make([]T, n)...)[:len(s)]
}

BenchmarkGeneric2-24    	35662242	        37.90 ns/op	     112 B/op	       1 allocs/op

It seems that somehow [S ~[]E, E any](s S) instead of [E any](s []E) as the signature makes the difference.

[dsnet]

Okay, the following fixes the optimization:

func genericExtend[S ~[]E, E any](s S, n int) S {
	return S(append([]E(s)[:cap(s)], make([]E, n)...)[:len(s)])
}

where we directly cast S to []E.

[dsnet]

More details: It seems that this is unrelated to generics, but rather that the growslice optimization simple does not work with named slices. This benchmark also allocates twice and does not use generics:

func BenchmarkConcrete2(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		s = nil
		bytesExtend2(s, n)
	}
}

type S []byte
func bytesExtend2(s S, n int) S {
	return append(s[:cap(s)], make(S, n)...)[:len(s)]
}

BenchmarkConcrete2-24    	18076892	        68.63 ns/op	     224 B/op	       2 allocs/op

[gopherbot]

Change https://go.dev/cl/417494 mentions this issue: slices: avoid mutating elements between length and capacity in Grow

[dsnet]

I looked briefly into what was going with the compiler. It seems that this is a bug in the type-checker. If the expression is make([]E, n), the ir.Node.Op is correctly identified as ir.OMAKESLICE. However, when the expression is make(S, n), it strangely becomes ir.OCONVNOP, which breaks the optimization.

[gopherbot]

Change https://go.dev/cl/418475 mentions this issue: cmd/compile: avoid assignment conversion in append(a, b...)

[gopherbot]

Change https://go.dev/cl/418514 mentions this issue: [dev.unified] cmd/compile: make Unified IR always writes concrete type for expressions

[gopherbot]

Change https://go.dev/cl/422037 mentions this issue: cmd/compile: disable append of make test on noopt builder

[gopherbot]

Change https://go.dev/cl/422040 mentions this issue: cmd/compile: do not write implicit conversion for append in Unified IR