search for: initialexec

...menting the possibility of having a small amount of initial-exec in a dso that is dlopend would be a bad idea, as it would prevent the compiler from lowering a variable to initial-exec as that might go over the limit. Something high level like: > * localdynamic: Only used from this DSO. > * initialexec: Will not be loaded dynamically. > * localexec: Will be in the executable and is only used from it. is probably OK. >> +    default: // Map unknown non-zero value to default. >> >> Why? > > Lots of other functions in the file do this, for example > GetDecodedLinkage...

...e 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 supported by the target would be illegal. If a model is not specified, the target gets to choose the appropriate model, as it does today. Clang would need t...

...ones. The rest of the review: + separated copy of the variable). Optionally, a suggested TLS model may be Not sure I would call it "suggested". What it is is a promise by the FE/user that some restrictions apply to how the variable is used: * localdynamic: Only used from this DSO. * initialexec: Will not be loaded dynamically. * localexec: Will be in the executable and is only used from it. The restrictions should be documented too. + bool isThreadLocal() const { return threadLocalMode; } Add a != NotThreadLocal to make it explicit. + default: // Map unknown non-zero value to defau...

...gt; +   separated copy of the variable). Optionally, a suggested TLS model may be > > Not sure I would call it "suggested". What it is is a promise by the > FE/user that some restrictions apply to how the variable is used: > > * localdynamic: Only used from this DSO. > * initialexec: Will not be loaded dynamically. > * localexec: Will be in the executable and is only used from it. > > 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 g...

.... 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(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 supported by the > target would be illegal. If a model is not specified, the target gets > to choose the appropriate model, as it does to...

...ng a small amount of initial-exec in a dso that is dlopend > would be a bad idea, as it would prevent the compiler from lowering a > variable to initial-exec as that might go over the limit. > > Something high level like: > >> * localdynamic: Only used from this DSO. >> * initialexec: Will not be loaded dynamically. >> * localexec: Will be in the executable and is only used from it. > > is probably OK. I've put that in the doc. We can tweak it more after commit if necessary. >>> And this return is dead, you can use llvm_unreachable. >> >>...

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.

> 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 *) This

Currently it appears X86WrapperRIP is only implemented in the small code model, which causes code to fail to select in other code models. My particular use case is MCJIT, where the default code model is large (the X86WrapperRIP comes from a TLS variable reference). What would be the best way to implement this? I'd be happy to take a crack at it myself, but I really don't know my way around