> On Thu, 5 May 2022, Jan Hubicka wrote: > > > Also note that visibility pass is run twice (once at compile time before > > early optimizations and then again at LTO). Since LTO linking may > > promote public symbols to local/hidden, perhaps we want to do this only > > second time the pass is executed? > > The first pass appears to be redundant and could be avoided, yes. > > > What is the reson we avoid using LOCAL_DYNAMIC with !optimize while we > > are happy to use LOCAL_EXEC with !optimize !flag_shlib? > > It follows from how local-dynamic model is defined: we call __tls_get_addr > with an argument that identifies the current DSO (not the individual > thread-local variable), and then compute the address of the variable with > a simple addition, so when there are two or more TLS variables, we can > call __tls_get_addr just once (but at -O0 we will end up with redundant > calls).
Thanks for explanation. So this is something that really depends on optimization flags of the function referring the variable rather than on optimization flags of the variable itself and only makes difference if there is -O0 function that contains more than one reference to a TLS var? I guess then a correct answer would be to search for such references. What happens when there are multiple object files with a hidden TLS var where some gts LOCAL_DYNAMIC and others GLOBAL_DYNAMIC? (Which may happen when linking together object files compiled with different versions of compiler if we go ahead with this patch on hidden symbols). Honza > > There's no such concern for local-exec vs initial-exec promotion. > > Alexander
