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/gc: specify that C or assembly function arguments do not escape #4099

Closed
rsc opened this Issue Sep 18, 2012 · 8 comments

Comments

Projects
None yet
4 participants
@rsc
Contributor

rsc commented Sep 18, 2012

It would be nice if there were a way to tell gc that an external function (written in C
or assembly) does not let its arguments escape. Right now sometimes it is faster to
execute Go than assembly because the Go code has better escape analysis while gc assumes
the worst about assembly.
@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 18, 2012

Contributor

Comment 1:

I regret that I can only vote once for this issue.
Contributor

davecheney commented Sep 18, 2012

Comment 1:

I regret that I can only vote once for this issue.
@DanielMorsing

This comment has been minimized.

Show comment
Hide comment
@DanielMorsing

DanielMorsing Sep 19, 2012

Contributor

Comment 2:

Could some sort of label for arguments be worked into the upcoming TYPE change in the
assembler? Not sure what the syntax would be, but the TYPE instruction does provide a
convenient place to put this information.
Contributor

DanielMorsing commented Sep 19, 2012

Comment 2:

Could some sort of label for arguments be worked into the upcoming TYPE change in the
assembler? Not sure what the syntax would be, but the TYPE instruction does provide a
convenient place to put this information.
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Oct 6, 2012

Contributor

Comment 3:

Labels changed: added go1.1.

Contributor

rsc commented Oct 6, 2012

Comment 3:

Labels changed: added go1.1.

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Dec 10, 2012

Contributor

Comment 4:

Labels changed: added size-l.

Contributor

rsc commented Dec 10, 2012

Comment 4:

Labels changed: added size-l.

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Dec 15, 2012

Contributor

Comment 5:

@rsc. Daniel Morsing and I played with this a few months back in the context of avoiding
arguments passed to arm functions not escape. Specifically syscall.Syscall*'s where the
[]byte passed to syscall.Read() and friends was made to not escape.
Disappointingly we couldn't detect any significant improvement in the go1 benchmarks.
@dmorsing - do you still have that CL ?
Contributor

davecheney commented Dec 15, 2012

Comment 5:

@rsc. Daniel Morsing and I played with this a few months back in the context of avoiding
arguments passed to arm functions not escape. Specifically syscall.Syscall*'s where the
[]byte passed to syscall.Read() and friends was made to not escape.
Disappointingly we couldn't detect any significant improvement in the go1 benchmarks.
@dmorsing - do you still have that CL ?
@DanielMorsing

This comment has been minimized.

Show comment
Hide comment
@DanielMorsing

DanielMorsing Dec 19, 2012

Contributor

Comment 6:

Unfortunately I've lost the CL.
I think the advantage is limited, since the only use of external functions with pointer
parameters I have found are the syscall Read and Write functions. Most of those calls
are pointed somewhere in the heap anyway.
Contributor

DanielMorsing commented Dec 19, 2012

Comment 6:

Unfortunately I've lost the CL.
I think the advantage is limited, since the only use of external functions with pointer
parameters I have found are the syscall Read and Write functions. Most of those calls
are pointed somewhere in the heap anyway.
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Feb 3, 2013

Contributor

Comment 7:

Suggestion at CL 7289048.
Contributor

rsc commented Feb 3, 2013

Comment 7:

Suggestion at CL 7289048.
@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Feb 5, 2013

Contributor

Comment 8:

This issue was closed by revision fd178d6.

Status changed to Fixed.

Contributor

rsc commented Feb 5, 2013

Comment 8:

This issue was closed by revision fd178d6.

Status changed to Fixed.

@rsc rsc added fixed labels Feb 5, 2013

@rsc rsc self-assigned this Feb 5, 2013

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015

@rsc rsc removed the go1.1 label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.