cmd/compile: optimize single return value type assertion

[valyala]

This is a follow-up for #17118 .

Currently in go tip single return value type assertion is much slower comparing to type assertion returning two values:

func BenchmarkTypeAssertSingleReturnValue(b *testing.B) {
        n := 42
        v := interface{}(n)
        for i := 0; i < b.N; i++ {
                a := v.(int)
                if a != n {
                        b.Fatalf("unexpected a: %d. Expecting %d", a, n)
                }
        }
}

func BenchmarkTypeAssertTwoReturnValues(b *testing.B) {
        n := 42
        v := interface{}(n)
        for i := 0; i < b.N; i++ {
                a, ok := v.(int)
                if !ok {
                        b.Fatalf("type assertion failed for v=%v", v)
                }
                if a != n {
                        b.Fatalf("unexpected a: %d. Expecting %d", a, n)
                }
        }
}

Results:

BenchmarkTypeAssertSingleReturnValue-4      200000000            7.97 ns/op        0 B/op          0 allocs/op
BenchmarkTypeAssertTwoReturnValues-4        2000000000           1.09 ns/op        0 B/op          0 allocs/op

The compiler may optimize single return value type assertion (x := v.(T)) by rewriting it into the following code:

x, ok := v.(T)
if !ok {
    panic(...)
}

[valyala]

cc'ing @randall77

[kvu787]

I've found that checked scalar type assertions:

x, ok := y.(T) // T is scalar type

are much faster than other type assertions.

This commit inlines checked scalar type assertions: 615a52b

Before commit benchmarks:

BenchmarkTypeAssertSingleReturnValue-4    200000000         10.0 ns/op
BenchmarkTypeAssertTwoReturnValues-4      100000000         10.4 ns/op

After commit benchmarks:

BenchmarkTypeAssertSingleReturnValue-4    100000000         11.1 ns/op
BenchmarkTypeAssertTwoReturnValues-4      2000000000         1.54 ns/op

Can unchecked scalar type assertions (x := y.(int)) also be inlined?

[randall77]

I'll see if I can get in a fix for this before the freeze.

[gopherbot]

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

[gopherbot]

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