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

[Hans Wennborg]

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.

Thanks,
Hans

>> The attached patch takes a stab at fixing PR14309 which was marked as
>> a 3.2-blocker.
>>
>> For global variables which get the same value stored into them
>> everywhere, GlobalOpt will replace them with a constant. The problem
>> is that a thread-local GlobalVariable looks like one value, but is
>> different between threads.
>>
>> My patch introduces Constant::isThreadDependent() which returns true
>> for thread-local variables and constants which depend on them (e.g. a
>> GEP into a thread-local array), and teaches GlobalOpt not to track
>> such values.
>>
>> Please take a look!
>>
>> Also, if anyone thinks there are more passes which assume that
>> thread-local GlobalVariables have the same value everywhere, please
>> let me know.