On 05/23/2013 12:20 PM, Jakub Jelinek wrote:
> On Thu, May 23, 2013 at 12:06:01PM -0700, Richard Henderson wrote:
>>> struct foo_c_state
>>> {
>>> some_type bar;
>>> };
>>> # define bar ctxt->x_foo_c_bar;
>>> /* there's a "context *ctxt;" variable somewhere, possibly
>>> using TLS */
>>
>> I've an idea that this will perform very badly. With ctxt being a global (if
>> tls) variable, it's call clobbered. Thus we'll wind up reloading it all the
>> time, which for pic involves another call to the __get_tlsaddr runtime
>> function.
>
> If all of gcc just has one __thread pointer in it, then we can just use
> tls_model ("initial-exec") for it and lower that overhead down a lot.
Not available on emutls systems. But even with initial-exec the overhead is a
lot more than having the value stored within the local stack frame.
TLS is great for passing around rarely used state, which might be needed 10
call frames down but not in between. E.g. any state for the presumed
per-thread memory allocator.
But it's not nearly so good for pass-specific data that potentially every
function within the pass might need.
r~
