On Thu, 5 May 2022, Jan Hubicka wrote: > > 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?
Well, for an -O0 function it doesn't matter how many different TLS variables it is referencing. The interesting case is an -O2 function referencing one local-dynamic TLS variable. > I guess then a correct answer would be to search for such references. Presumably at RTL generation time, i.e. let the middle end discover the most specific TLS access model, and then selectively downgrade local-dynamic to global-dynamic when lowering an -O0 function. > 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). They have different relocations, so there's an increase in number of GOT entries, but otherwise I don't think there's any problem. Alexander
