I like it. Seems like a solid, easy win.

cc @martisch

Interestingly i had been working on optimizing runtime.intstring this week (which uses slicebytetostringtmp) and had a similar thought for lowering this too :)

Will work to implement it and it fits nicely with other CLs i work on for runtime string/rune .

I started a CL to do the lowering in the backend when not instrumenting as it is more direct than expressing _(_string)(unsafe.Pointer(&b)) in the frontend and then hope the ssa optimizations figure out that indirections are not needed.

Can we let the frontend generate code to use the runtime function when ssaEnabled is not true since the non-ssa backend is likely to be removed for 1.8 anyway or would that be a violation of the separation between the stages?

OARRAYBYTESTRTMP does not sound like a good name to me. Something like OSLICEBYTETOSTRTMP or OSLICEBYTETOSTRNOCOPY might be better? Later sounds more universal and can be used for all kinds of mappings in the compiler which we deem save and where we keep either byteslice or str around afterwards.

Other string functions (e.g. stringtoslicebytetmp) seem to be also good candidates to be handled directly by either frontend or backend instead of a runtime function.

CL https://golang.org/cl/29017 mentions this issue.

Can we let the frontend generate code to use the runtime function when ssaEnabled is not true since the non-ssa backend is likely to be removed for 1.8 anyway or would that be a violation of the separation between the stages?

It might take a bit of work to get ssaEnabled available earlier in the compiler.

We've resisted doing this so far, in part to make it easier for people working on the migration. However, maybe it's time. Then we could start now on eliminating bits of the mid-tier in a way that'd be easy to cope with when the old backend is gone for good. Thoughts, @randall77?

OARRAYBYTESTRTMP does not sound like a good name to me.

In very old versions of the compiler, there were no slices in Go yet, only arrays. Slices were clearly then hacked in as array variants. We've been slowly cleaning that up ever since (only last week I separated OSLICELIT from OARRAYLIT). So yeah, we should do a bunch of renaming at some point.

Still sitting in my pile of unmailed CLs:

gorename -from '"cmd/compile/internal/gc".OPROC' -to OGO

TODO:
OARRAYBYTESTR
OARRAYBYTESTRTMP
OARRAYRUNESTR
OSTRARRAYBYTE
OSTRARRAYBYTETMP
OSTRARRAYRUNE

and

cmd/compile: add Node.IsMethod method

Generated by eg:

func before(n *gc.Node) bool { return n.Type.Recv() != nil }
func after(n *gc.Node) bool  { return n.IsMethod() }

func before(n *gc.Node) bool { return n.Type.Recv() == nil }
func after(n *gc.Node) bool  { return !n.IsMethod() }

Other string functions (e.g. stringtoslicebytetmp) seem to be also good candidates to be handled directly by either frontend or backend instead of a runtime function.

SGTM

I'd rather avoid backend-dependent phases in the frontend. It will lead to very confusing code. I'd rather wait until the old backend is deleted and then do it unconditionally.
Another option is to semantically inline slicebytetostringtmp in the SSA builder. All of the runtime/internal/atomic intrinsification works this way.