[llvm-commits] [Patch] Make GlobalOpt conservative with TLS vars (PR14309, 3.2-blocker)

Hans Wennborg hans at chromium.org
Thu Nov 15 04:12:17 PST 2012


On Wed, Nov 14, 2012 at 11:01 AM, Hans Wennborg <hans at chromium.org> wrote:
> On Wed, Nov 14, 2012 at 8:22 AM, Duncan Sands <baldrick at free.fr> wrote:
>> Hi Hans, any suggestions for a redesign of TLS that makes this kind of
>> problem impossible?
>
> No good ones, unfortunately.
>
> The fundamental problem is that thread-local GlobalVariable is also a
> Constant, which it shouldn't be. Clang already knows not to treat
> allow TLS variables in constant initializers (PR13720).
>
> TLS variables do have all the other properties that GlobalVariable
> has. Could we split GlobalVariable into a base class which doesn't
> inherit from Constant that could be used for TLS variables, and a
> ConstGlobalVariable used for non-TLS ones?
>
> When we talked about this on IRC, Chandler mentioned that maybe we
> should never allow direct access to a TLS GlobalVariable, but always
> access it through an intrinsic: "%tls.ptr = call i32*
> @llvm.get_tls_ptr(<opaque>* @global)". I guess we'd have to teach some
> analyses that this intrinsic always returns the same value within a
> function, and we could update the verifier to check that TLS variables
> are never used anywhere except as arguments to this intrinsic.
>
> More thoughts on this would be very welcome.

I've filed PR14353 to track this.

 - Hans



More information about the llvm-commits mailing list