cmd/compile: optimize reflect.Value.Set with short-lived Values

[dsnet]

Some accessor reflect.Value methods must allocate since they return value that references an underlying value that must be heap allocated.

Such patterns include:

v1.Set(v2.MapIndex(...))
v1.Set(v2.Slice(...))
v1.Set(v2.Slice3(...))

In such a usage, the generated value could be stack allocated since it only used as an intermediate storage before the value is stored into v1.

[prattmic]

cc @golang/compiler

[cherrymui]

What could be stack allocated? You mean the Value struct? Or the underlying data, like the slice header for the v2.Slice case? Thanks.

[dsnet]

In the case of Value.MapIndex, it would be the final call to copyVal:

go/src/reflect/value.go

Line 1755 in 185e1a7

return copyVal(typ, fl, e)

Suppose we refactored to Value.MapIndex to be inlinable, where the call to copyVal was part of the inlined portion, I wonder if the compiler can detect that the returned Value does not escape and cause the call to unsafe_New in copyVal to be stack allocated:

go/src/reflect/value.go

Line 1977 in 185e1a7

c := unsafe_New(typ)

I'm not sure if that's possible though, since the size of a stack allocated object usually needs to be known at compile time. In this situation we don't know.

The alternative is to avoid copyVal entirely if the compiler detects that the Value is directly passed to Value.Set. It's okay if we temporarily pass a value that addresses a map value if we know that it is short-lived. However, this seems like a fairly specific compiler hack that depends on particular ways that reflect is implemented today.