similar to: [LLVMdev] Adding support for explicitly specified TLS models (PR9788)

Reviving this thread with a patch! And some comments inline. Please take a look and let me know what you think. - Hans On Wed, Apr 25, 2012 at 12:39 PM, Hans Wennborg <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

On Tue, Jun 12, 2012 at 7:05 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > 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.

On Tue, Jun 12, 2012 at 07:21:17PM +0100, Hans Wennborg wrote: > On Tue, Jun 12, 2012 at 7:05 PM, Joerg Sonnenberger > <joerg at britannica.bec.de> wrote: > > 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

On Wed, Apr 25, 2012 at 12:39:49PM +0100, Hans Wennborg wrote: > Just as it is illegal to specify thread_local for a target that > doesn't support it, specifying a TLS model that isn't supported by the > target would be illegal. For ELF, it doesn't make sense to reject one as it can always be relaxed. An application program shouldn't have to worry about that, it is just

On Wed, Apr 25, 2012 at 14:04, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Apr 25, 2012 at 12:39:49PM +0100, Hans Wennborg wrote: >> Just as it is illegal to specify thread_local for a target that >> doesn't support it, specifying a TLS model that isn't supported by the >> target would be illegal. > > For ELF, it doesn't make sense

>> 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

On Tue, Jun 12, 2012 at 3:41 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> 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 >>

> 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.

> 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 wouldn't be detectable:

On Thu, Jun 14, 2012 at 9:33 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> 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

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

(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.

> OK, let's go with GeneralDynamicTLSModel then. OK >> The restrictions should be documented too. > > I'm not sure how much detail we should go into here, because the > restrictions might vary depending on the environment. For example, > with glibc, it will be possible to use initial-exec in a .so that will > be loaded dynamically, given that the amount of tls

> 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

Thanks for the review! Comments inline; new patch attached. On Thu, Jun 21, 2012 at 8:40 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> If we don't want to do that, I think we should try to add the new >> constructors while keeping the old ones around, and then delete the >> old constructors once clang is updated. > > Yes, this would probably be

On Sat, Jun 23, 2012 at 1:35 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > It is probably better to be more strict than any particular > implementation. The description on the IL definition is all the > optimizers have to play with. For example, documenting the possibility > of having a small amount of initial-exec in a dso that is dlopend > would be a bad

> I managed to dig out the original thread for GCC: > http://gcc.gnu.org/ml/gcc-patches/2002-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

> If we don't want to do that, I think we should try to add the new > constructors while keeping the old ones around, and then delete the > old constructors once clang is updated. Yes, this would probably be the best. To make clang build I just hacked the constructors in the patch I posted, but they should really just forward to the new ones. >> *) Please name the most general

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, >>>