I think it's almost always a win to start on the stack, if we can.

This example is tricky, and probably very common:

var b []byte
for ... {
    b = append(b, ...)
}

How do we preallocate some space for b? We'd want to do:

var bStore [32]byte  // on stack
b := bStore[:0]

But that isn't right if for loop runs for 0 iterations. The result must be nil (and have 0 capacity).

I wonder if always applying this transformation, even if it never hurt performance, would make binaries noticeably bigger.

Would this be done for all allocations of small non-escaping slices? Or only for those where the capacity is known at compile time to be small?

We already allocate small non-escaping slices on the stack if their capacity is known at compile time.
This issue would be about when the size is not known at compile time.

Is this #20533?

It's definitely similar. #20533 is going more down the road of really allocating n bytes when you do a := make([]byte, n) (alloca-style, or on the heap with explicit free). This one is about allocating a constant size buffer and only using it when n is small enough.

Transforming a := make([]byte, n) into:

var a []byte
if n < 64 {
    a = make([]byte, n, 64)   // stack allocation
} else {
    a = make([]byte, n)       // heap allocation
}

can surely have some code size impact. In some cases, maybe prove is able to remove one of the two branches but I'm not holding my breath on that. I wonder if it's still worth, performance wise.

We should also explore doing this for slices of different types (while keeping total stack allocation within a certain limit).

Transforming a := make([]byte, n) into ...

Recent example where such transformation was done by hand for performance: 17d5cef (CL 230657).

/cc @martisch