Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: emits unnecessary deferreturn #5712

Open
dvyukov opened this issue Jun 15, 2013 · 9 comments

Comments

@dvyukov
Copy link
Member

commented Jun 15, 2013

parent: 17086:2879112bff3d tip, linux/amd64

The program is:

package main

import "sync"

func main() {
    println(foo(0))
}

func foo(x int) int {
    // fast path
    if x != 42 {
        return x
    }
    // slow path
    mu.Lock()
    defer mu.Unlock()
    seq++
    return seq
}

var (
    mu  sync.Mutex
    seq int
)

The generated code for fast path is:

func foo(x int) int {
  400c40:       64 48 8b 0c 25 f0 ff    mov    %fs:0xfffffffffffffff0,%rcx
  400c47:       ff ff 
  400c49:       48 3b 21                cmp    (%rcx),%rsp
  400c4c:       77 05                   ja     400c53 <main.foo+0x13>
  400c4e:       e8 bd 81 01 00          callq  418e10 <runtime.morestack16>
  400c53:       48 83 ec 08             sub    $0x8,%rsp
  400c57:       48 8b 44 24 10          mov    0x10(%rsp),%rax
  400c5c:       48 c7 44 24 18 00 00    movq   $0x0,0x18(%rsp)
  400c63:       00 00 
        if x != 42 {
  400c65:       48 83 f8 2a             cmp    $0x2a,%rax
  400c69:       74 0f                   je     400c7a <main.foo+0x3a>
                return x
  400c6b:       48 89 44 24 18          mov    %rax,0x18(%rsp)
        }
        mu.Lock()
        defer mu.Unlock()
        seq++
        return seq
}
  400c70:       e8 eb b7 00 00          callq  40c460 <runtime.deferreturn>
  400c75:       48 83 c4 08             add    $0x8,%rsp
  400c79:       c3                      retq   


If the compiler performs some CFG analysis, it can figure out that 'callq
runtime.deferreturn' is unnecessary in this case.
@DanielMorsing

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2013

Comment 1:

We have some other issues that could use dataflow analysis to solve them, For example
issue #5364. It would be a good idea to have a general way of doing DFA. Maybe roll in
escape analysis.
@bradfitz

This comment has been minimized.

Copy link
Member

commented Jun 18, 2013

Comment 2:

Labels changed: removed priority-triage.

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 3:

The analysis here can be pretty basic. If the return is above the defer and not in a
loop or after a goto'ed label, it doesn't need the deferreturn.

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 4:

Labels changed: added feature.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2013

Comment 5:

Not for 1.2.

Labels changed: removed go1.2maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 7:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 9:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title cmd/gc: emits unnecessary deferreturn cmd/compile: emits unnecessary deferreturn Jun 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.