cmd/compile: ineffective branch caused by defer

[mariecurried]

What version of Go are you using (go version)?

$ go version
go version devel +d410642 Mon Jul 1 21:30:23 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

I was testing the behavior of defer, so I ended up compiling the following functions (https://godbolt.org/z/uALdNA):

package test

func f() {
}

func usef() {
    defer f()
}

What did you expect to see?

I expected the generated assembly to not contain any unnecessary branches.

What did you see instead?

Instead, there is a repeated block of instructions that is preceded by a condicional jump (https://godbolt.org/z/uALdNA):

        testl   AX, AX
        jne     applyf_pc83
        xchgl   AX, AX
        call    runtime.deferreturn(SB)
        movq    64(SP), BP
        addq    $72, SP
        ret
applyf_pc83:
        xchgl   AX, AX
        call    runtime.deferreturn(SB)
        movq    64(SP), BP
        addq    $72, SP
        ret

[ianlancetaylor]

CC @randall77

[randall77]

This is known. One return path is the normal return path, and one is the panic/recover return path. Each has a call to deferreturn. We don't share epilogues at the moment, see #24936 for some discussion.

In any case, this bug will probably become obsolete once we fix #14939.

But I'll leave this open for now. I couldn't find an issue explicitly about epilogue sharing (which this is), so might as well use this one.