(Related switch-optimization issues are #5496 and #15780.)

A similar return-twice pattern happens for defer. If possible we should do a similar thing for defers.

@randall77 I think cleaning up deferproc is likely worth doing for similar reasons, but I think the details are distinct enough to track in a separate proposal.

I like it. Most select cases are small (https://github.com/josharian/countselectcases/blob/master/README.md has some old data), so it'll be a linear not binary search, but I'd wager it'll be imperceptible, particularly since we're eliminating a linear number of function calls.

I admit that I don't fully understand the reasons why it's done the way it is today, but I support this change, too. In addition to dramatically simplifying some very strange semantics in the runtime, this would eliminate the only use of setcallerpc in the runtime, which has been a thorn in my side before.

I believe it would eliminate the only use of setcallerpc anywhere.

I'm all for this. The suggestion approach seems much cleaner.

One minor complication I discovered while prototyping this: currently we perform race instrumentation within selectgo using the caller PCs recorded by select{send,recv,default}. This shows up when case ch <- v: races with close(ch) or case v = <-ch: races with another load/store of v.

We could continue instrumenting within selectgo, but it would mean any races would point to the entire select statement, rather than the individual case.

Alternatively, we can have the compiler insert instrumentation around the selectgo call, so they can have appropriate line numbers and precise race reports. This would amount to a raceread call for each send case, and just rewriting case v = <-ch: to case vtmp := <-ch: v = vtmp (which we already do at least in some cases) so the compiler's usual instrumentation pass can handle it.

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

CL 37661 gets rid of the setjmp/longjmp control flow, but keeps the selectfoo calls in place for the purpose of race instrumentation. Post-walk, the AST now looks like:

var sel struct { ... }
runtime.newselect(&sel, unsafe.Sizeof(sel), 4)
runtime.selectsend(&sel, c1, &v1)
runtime.selectrecv(&sel, c2, &v2, nil)
runtime.selectrecv(&sel, c3, &v3, &ok)
runtime.selectdefault(&sel)
chosen := runtime.selectgo(&sel)
if chosen == 0 { f1(); goto after }
if chosen == 1 { f2(); goto after }
if chosen == 2 { f3(); goto after }
if chosen == 3 { f4(); goto after }
undef
after:

Further simplifications are still possible.

If this makes things better for you, great. I can see select getting better from this. I am not as sure about being able to do the same for deferreturn. That will be harder due to stack frame layouts.

Closing as the core issue (eliminating setjmp/longjmp in select) is fixed.

It also occurs to me that deferreturn has basically none of the control flow issues that select did. In effect deferreturn just backs up the PC by 1 to cause itself to run again as a simple way to cause a loop. But to any control flow analysis of the code involved, that's indistinguishable from deferreturn containing a loop and only returning once. So it probably isn't worth changing.

The issue with defer for me is not with deferreturn, it is with deferproc returning twice (once when first called, again when an panic occurs and that defer recovers).
It would be nice if we could arrange that defer to return directly to the deferreturn call instead of to immediately after the deferproc call. In any case, something for another issue.