search for: dlopend

Displaying 4 results from an estimated 4 matches for "dlopend".

Did you mean: dlopen
2012 Jun 23
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...;ve tried to update the > text to do that. 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 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...
2012 Jun 23
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
...la 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 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. >> * lo...
2012 Jun 22
0
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
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
2012 Jun 21
2
[LLVMdev] [llvm-commits] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)
> 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