declaration.
search for the annotation in the go tree for examples.
On Jul 19, 2013 2:00 AM, "Nick Craig-Wood" wrote:
http://golang.org/cmd/gc/ - compiler directives ;-)
I can't seem to make it work though :-(
I made a before and after test here to demonstrate. I hope I'm just
doing something stupid!
https://github.com/ncw/go-noescape-test
Thanks in advance for any help!
stack
http://www.craig-wood.com/nick
Groups "golang-nuts" group.
send an email to golang-nuts+unsubscribe@googlegroups.com.
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--On 17/07/13 23:14, Dave Cheney wrote:
It's an undocumented secret annotation that only the gc compilers
support. Don't tell anyone.It's an undocumented secret annotation that only the gc compilers
http://golang.org/cmd/gc/ - compiler directives ;-)
I can't seem to make it work though :-(
I made a before and after test here to demonstrate. I hope I'm just
doing something stupid!
https://github.com/ncw/go-noescape-test
Thanks in advance for any help!
On 18/07/2013, at 8:08, Nick Craig-Wood wrote:
Exactly what I was looking for - thanks!
It didn't work immediately - I'll try some more in the morning.
Exactly what I was looking for - thanks!
It didn't work immediately - I'll try some more in the morning.
On 17/07/13 22:47, Dave Cheney wrote:
Grep for //go:noescape
Grep for //go:noescape
On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
I've noticed that re-writing functions in assembler seems to disable
Go's escape analysis.
In the particular example I'm working on that causes go to allocate
objects on the heap rather than the stack in the calling Go function
which for some test cases outweighs the goodness of converting the
called function to assembler!
To be specific in the below g() has been converted to assembler. That
seems to force f() to allocate `data` on the heap rather than the
I've noticed that re-writing functions in assembler seems to disable
Go's escape analysis.
In the particular example I'm working on that causes go to allocate
objects on the heap rather than the stack in the calling Go function
which for some test cases outweighs the goodness of converting the
called function to assembler!
To be specific in the below g() has been converted to assembler. That
seems to force f() to allocate `data` on the heap rather than the
like it used to when g() was in Go.
func f() {
var data [64]byte
g(data)
}
Any ideas on how to get round this?
Thanks
Nick
--
Nick Craig-Wood <nick@craig-wood.com> --
func f() {
var data [64]byte
g(data)
}
Any ideas on how to get round this?
Thanks
Nick
--
Nick Craig-Wood <nick@craig-wood.com> --
--
You received this message because you are subscribed to the Google
You received this message because you are subscribed to the Google
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
