search for: pr9788

...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_local attribute, like this: > >  @x = thread_local(...

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

On Wed, Apr 25, 2012 at 03:17:13PM +0100, Hans Wennborg wrote: > 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

On Tue, Jun 12, 2012 at 10:41:37AM -0400, Rafael Espíndola 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 > > it would be unfortunate

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

> 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

Hi Rafael, > I kind of agree with the intuition, but If you don't mind I would > probably ask for something stronger before changing the IL. If we do > find a case where for some reason the compiler cannot optimize the > model, adding a 'default' to the IL should be easy. > > Duncan, you know the gcc internals, any thoughts? I don't know anything about TLS

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

On Mon, Jun 4, 2012 at 11:10 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 4 June 2012 10:49, Hans Wennborg <hans at chromium.org> wrote: >> Reviving this thread with a patch! >> >> And some comments inline. >> >> Please take a look and let me know what you think. > > Just a high level comment, why do you need the 4 modes +

On Fri, Apr 27, 2012 at 09:19:32AM +0100, Hans Wennborg wrote: > On Thu, Apr 26, 2012 at 01:10, Joerg Sonnenberger > <joerg at britannica.bec.de> wrote: > >> > 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 an implementation detail.

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

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 support it, specifying a TLS model that isn't suppo...

On 4 June 2012 10:49, Hans Wennborg <hans at chromium.org> wrote: > Reviving this thread with a patch! > > And some comments inline. > > Please take a look and let me know what you think. Just a high level comment, why do you need the 4 modes + default? Can't clang just produce globaldynamic (or the attribute value) and let llvm optimize it? Since in the end the linker is

> 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

On Thu, Apr 26, 2012 at 01:10, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> > 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 an implementation detail. >> >> I'd be fine with that. >> >> (Clang should still worry

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

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

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