On Jul 2, 2011, at 2:42 PM, Simon Marlow wrote: > On 02/07/11 19:34, David Peixotto wrote: > >> The best we could hope for would be for an access of `gct` to turn >> into something like this in the GC: > > >> movq (%rdi),%rdi #deref the key which is an index into the tls memory >> movq %gs:0x00000060(,%rdi,8),%rax # read the value indexed by the key >> >> but it looks like we are getting something like this: >> >> call getThreadLocalVar >> movq (%rdi),%rdi #deref the key which is an index into the tls memory >> jmp<dynamic_linker_stub> >> movq %gs:0x00000060(,%rdi,8),%rax #pthread_getspecific body >> ret > > you don't need to go through getThreadLocalVar, right? Just call > pthread_getspecific directly.
Yeah, I can change it to be a direct call to pthread_getspecific. I was just trying to reuse the existing GHC api for thread local storage, and I thought the call would be inlined away. > I don't know why it's going through the dynamic linker stub, I thought it was > supposed to be #defined to the inline assembly. I can't see any obvious definition in the header files on my machine. The definition I found is an assembly file that is part of apples libc implementation: http://www.opensource.apple.com/source/Libc/Libc-594.9.5/x86_64/pthreads/pthread_getspecific.s This definition seems to match what I see when I debug an executable in gdb. > Anyway, the last resort will be to pass gct as a parameter to the critical > functions in the GC - scavenge_block() and everything it calls transitively, > including evacuate(). This is likely to give quite good performance, but not > as good as a register variable, so unfortunately we'll need some #ifdefery or > macros which will be quite ugly (hence why I say this is a last resort). Ok, hopefully we won't have to resort to that, but I'm not too optimistic at this point. If we are actually stuck dealing with the dynamic linker for pthread_getspecific then the overhead is going to probably be too high. _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
