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 support. Don't tell anyone.
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.
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick
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 stack
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> -- 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.
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 stack
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> -- 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.
--
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.
