On 05/19/09 12:10:43, Andrew Pinski wrote:
> Gary wrote:
> > Is the __thread feature now more universally/portably
> > supported?
>
> Yes, see emutls.c and the VAR_DECL case in expand_expr_addr_expr_1 and
> expand_expr_real_1 in expr.c.
> [...] for the emulated support which is
> implemented on the target side in emutls.c.
>
> On the tree level __thread looks the same for both the emulated and
> native supports.
Experimenting with this __thread emulation, a bit, I found that
the following configure options appear to enable TLS emulation:
--enable-threads=posix -disable-tls
(where --enable-threads is likely unnecessary on most
modern x86/Linux targets)
Trying the following simple test program:
__thread volatile int x;
int main ()
{
x = 1;
return x;
}
The following code was generated:
movl $__emutls_v.x, %edi
call __emutls_get_address
movl $1, (%rax)
movl $__emutls_v.x, %edi
call __emutls_get_address
movl (%rax), %eax
addq $8, %rsp
ret
Above, __emutls_get_address() is called twice, with
the same argument. I was surprised to see that the optimizer
(GCC 4.3.2) didn't notice this and use CSE to avoid the second
redundant call, because emultls_get_address is defined as
a "const" function:
DEF_EXT_LIB_BUILTIN (BUILT_IN_EMUTLS_GET_ADDRESS, "__emutls_get_address",
BT_FN_PTR_PTR, ATTR_CONST_NOTHROW_NONNULL)
Back to the issue at hand, it may turn out that GCC's TLS emulation
(thanks for pointing this out) will have acceptable performance
I'm still interested in understanding how to create a gimple
temporary that is set once upon entry to a function, so that its
value is available within the function's body.
thanks,
- Gary
