search for: globaldynam

> 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. > > Also, my patch does ma...

...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 allowed to relax tls access too, llvm should be allowed to make the mode more specific even if the user added an attribute at the C/C++ level. >  - Hans Cheers, Rafael

...;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 allowed to relax > tls access too, llvm should be allowed to make the mode more specific > even if the user added an attribute at the C/C++ level. I thought it was a good idea to make the user's choi...

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 >> it would be unfortunate if we'd have to go and change the IR format >> later because we limited ourselves here. >> &gt...

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 if we'd have to go and change the IR format > > later because we limited ourselves here. > &g...

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

...if someone else chimes in > or something new comes up. In the meantime, I'll rework the patch the > way you've suggested and if nothing's changed we can land it by the > end of next week. Sounds like a plan? Attaching a new patch that has the behaviour 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-...

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

> Attaching a new patch that has the behaviour 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. Awesome, thanks! I will try to do a more complete review tonight or tomorrow. For now, just two quick observations *)...

On Wed, Jun 20, 2012 at 9:29 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Attaching a new patch that has the behaviour 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. > > Awesome, thanks! > I will try to do a more complete review tonight or tomorrow. Great, loo...

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

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