search for: tls_model

...gt; > Ah, sorry. Because the compiler might not know it yet. Consider linking > code compiled with -fPIC into the main binary, either using PIE or not. Right, but the issue we're discussing here, is why GCC chooses to not optimize a variable like this: static __thread int __attribute((tls_model("global-dynamic"))) x; even if it could (e.g. when compiled without -fpic). We're trying to figure out if there's a good reason for this, and if we want to mimic that behaviour in LLVM, or if we should just take the tls_model attribute as a starting point, and choose a better mo...

...e compiler might not know it yet. Consider linking > > code compiled with -fPIC into the main binary, either using PIE or not. > > Right, but the issue we're discussing here, is why GCC chooses to not > optimize a variable like this: > > static __thread int __attribute((tls_model("global-dynamic"))) x; > > even if it could (e.g. when compiled without -fpic). > > We're trying to figure out if there's a good reason for this, and if > we want to mimic that behaviour in LLVM, or if we should just take the > tls_model attribute as a starting...

Hi all, I would like to hear your thoughts on adding support for extending the IR to allow for explicitly selecting which model to use for thread-local storage of a variable. The motivation is to allow Clang to support the "tls_model" variable attribute [1], as requested in PR9788. The idea would be to extend the IR to allow an optional TLS-model argument to the thread_local attribute, like this: @x = thread_local(initialexec) global i32 42 Just as it is illegal to specify thread_local for a target that doesn't su...

...<hans at chromium.org> wrote: > Hi all, > > I would like to hear your thoughts on adding support for extending the > IR to allow for explicitly selecting which model to use for > thread-local storage of a variable. > > The motivation is to allow Clang to support the "tls_model" variable > attribute [1], as requested in PR9788. This enables better performance for some code. For example, TCMalloc [3] would like to use the initial-exec model, because it's faster. > The idea would be to extend the IR to allow an optional TLS-model > argument to the thread...

On Tue, Jun 12, 2012 at 7:53 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> We're trying to figure out if there's a good reason for this, and if >> we want to mimic that behaviour in LLVM, or if we should just take the >> tls_model attribute as a starting point, and choose a better model if >> we can. > > On i386, non-PIC code can be used in shared libraries. If the TLS > variable itself is large, forcing global-dynamic makes sense. No idea if > anyone is insane enough to do that, but that's the case whe...

>> Do you know what is the rationale for that? The static linker will >> optimize it anyway (but not do as good a job as the compiler could). > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > needed. My point also :-) What I was asking for a rationale on was *not* doing the optimization in the compiler. > Joerg Cheers, Rafael

On Tue, Jun 12, 2012 at 12:36:28PM -0400, Rafael Espíndola wrote: > >> Do you know what is the rationale for that? The static linker will > >> optimize it anyway (but not do as good a job as the compiler could). > > > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > > needed. > > My point also :-) What I was asking for a

...-09/msg00668.html It doesn't give a rationale for the case we're discussing, though :/ My intuition still tells me that it would be good to separate the default and globaldynamic cases to 1) Respect the user's request: if the user went through the trouble of specifying __attribute__((tls_model("globaldynamic"))), we should assume there's a reason and give him what he wants, even if we think the linker is going to optimize it 2) To match GCC's behavior. I don't have any more compelling reasons than those, and I don't feel super strongly about this, so I'm wi...

...#39;s important that we get it right. I could have sworn I tried with -ftls-model yesterday, but apparently I didn't. Seems it works differently than I assumed (I guess I should have learnt not too assume things by now). Sorry about that. The point still stands, though: that code requires the tls_model attribute to be respected; if the compiler chooses local-exec instead, it won't be dlopen-able. The -ftls-model command-line flag has the behavior you describe: the user sets what the default model should be (global-dynamic if nothing else is specified), but if the compiler can choose a better...

> The point still stands, though: that code requires the tls_model > attribute to be respected; if the compiler chooses local-exec instead, > it won't be dlopen-able. This is a fairly contrived use case, and an extension of a gcc extension. > I think it adds value to make the behaviour the same as GCC's. And > it's not like the difference...

(To the list this time..) On Fri, Jun 15, 2012 at 7:38 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> The point still stands, though: that code requires the tls_model >> attribute to be respected; if the compiler chooses local-exec instead, >> it won't be dlopen-able. > > This is a fairly contrived use case, and an extension of a gcc extension. > >> I think it adds value to make the behaviour the same as GCC's. And >> it&...

> I thought it was a good idea to make the user's choice explicit in the > IR. If we combined the default and globaldynamic modes, LLVM wouldn't > be able to tell the difference. > > It may or may not be important to be able to tell the difference, but > it would be unfortunate if we'd have to go and change the IR format > later because we limited ourselves here.

...#39;t give a rationale for the case we're discussing, though :/ > > My intuition still tells me that it would be good to separate the > default and globaldynamic cases to > > 1) Respect the user's request: if the user went through the trouble of > specifying __attribute__((tls_model("globaldynamic"))), we should > assume there's a reason and give him what he wants, even if we think > the linker is going to optimize it > 2) To match GCC's behavior. > > I don't have any more compelling reasons than those, and I don't feel > super stron...

On Fri, Jun 15, 2012 at 9:56 PM, Hans Wennborg <hans at chromium.org> wrote: > (To the list this time..) > > On Fri, Jun 15, 2012 at 7:38 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >>> The point still stands, though: that code requires the tls_model >>> attribute to be respected; if the compiler chooses local-exec instead, >>> it won't be dlopen-able. >> >> This is a fairly contrived use case, and an extension of a gcc extension. >> >>> I think it adds value to make the behaviour the same as GCC...

> Right, that's a good point. > > On i386 Linux, the following code, > >  static __thread int x[100000]; >  int* get_x() { return x; } > > compiled with "clang -shared a.c -o a.so" won't be possible do dlopen. I get exactly the same result with gcc 4.7 with and without -ftls-model=global-dynamic: movq %gs:0, %eax addl $x at ntpoff, %eax > Rafael, I