IRC the compiler uses slicebytetostringtmp for concats if one of the non converted string concats is known to be non zero as there is an optimization that does not copy the content of the string if all other arguments of concat have zero length.

We could (and I had thought about that too after optimizing it by hand in real code) optimize string concats which are only in comparison. So generally e.g. string(a) + string(b) ...== string(c) + string(d) ... . Is the real program mentioned also using concat in a comparison?

IRC the compiler uses slicebytetostringtmp for concats if one of the non converted string concats is known to be non zero as there is an optimization that does not copy the content of the string if all other arguments of concat have zero length.

Good point.

We could (and I had thought about that too after optimizing it by hand in real code) optimize string concats which are only in comparison. So generally e.g. string(a) + string(b) ...== string(c) + string(d) ... . Is the real program mentioned also using concat in a comparison?

No, it wasn't in comparison. The string is parsed further and memorized in an escaping struct.
In my case the other string is usually non-empty, but compiler won't be able to figure it out statically (email subject).

You could try optimizing using e.g. (“a”+string(data)+str)[1:] to trigger slicebytetostringtmp until we find a nicer way for the compiler to understand that neither data nor str can be empty by e.g. using information from the prove pass for bounds checks and an additional length check in the code.

Alternatively like in this case we could make the compiler use a special concat call that always copies but also avoids all string allocations for string conversions.

One option here is that if the compiler can't prove that any of the strings are non-empty, it could just pass that information on to the runtime, so the runtime knows it can't do the return-without-copying optimization.

E.g., it could provide a uintptr bitset representing which string operands used slicebytetostringtmp. The runtime then just needs to do a single bit test to figure out if the optimization is safe. (And conservatively, we can't use slicebytetostringtmp for arguments past the first 32 or 64, depending on ptr-size, unless we know there's a non-empty string operand.)