This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/26461] liveness of thread local references across function calls


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Implementing a switch that assumes that function calls (what about async
events??) can switch threads to the effect that the location of TLS variables
change would be a challenge.  Basically you have to implement sth that prevents
assumptions of a variables location inside a function, not only its value. 
That's currently done nowhere and I don't know how to model such kind of
dependency.

So I don't think it's easy to model.  It might be possible to put in place
more strict constraints to avoid the issue, like instructing the compiler
that it can't ever take the address of a __tls object.  But then array
accesses are modeled as &A + index in the language so I can't see how this
would work reliably.

You'd have to expose __tls'ness by lowering that very early, not only during
RTL expansion.  That is, place TLS base reg loads and do accesses via them. 
Then
make sure calls clobber that base reg load.  So put all TLS data into sth like
a static frame where you'd have a global variable pointing to that.  I expect
this to be not-fun(TM) for performance.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]