search for: tls_models

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

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

...ariable-Attributes.html#index-g_t_0040code_007btls_005fmodel_007d-attribute-1797 > [2] http://www.akkadia.org/drepper/tls.pdf [3] http://code.google.com/searchframe#BGeH2W13jNw/trunk/src/thread_cache.h&l=257 -------------- next part -------------- A non-text attachment was scrubbed... Name: tls_models.diff Type: application/octet-stream Size: 36638 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120604/33a322f0/attachment.obj>

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

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

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

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

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

> 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

...iour we discussed. The "globaldynamic" and default values have been merged, and LLVM will start off with the user-specified model, but choose a more specific one if possible. Please review. Thanks, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: tls_models2.diff Type: application/octet-stream Size: 40607 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120620/ac5d72af/attachment.obj>

> 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