On Wed, May 20, 2009 at 12:47 AM, Gary Funck <g...@intrepid.com> wrote:
> 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.
This is likely because the libcall lacks a REG_EQUAL note (or
we lack something to put there). Tree level CSE would catch
it, but it doesn't see these function calls.
Richard.
> thanks,
> - Gary
>
