This is an archive of the discontinued LLVM Phabricator instance.

[builtins] Implement emulated TLS on Windows.
ClosedPublic

Authored by marsupial on Mar 9 2017, 12:25 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

marsupial created this revision.Mar 9 2017, 12:25 PM
chh accepted this revision.Mar 13 2017, 4:13 PM

I don't know if the WIN32 definitions are correct or not.
The non-WIN32 change looked good and compatible with current definitions.

This revision is now accepted and ready to land.Mar 13 2017, 4:13 PM

I don't have commit access...

chh added a comment.Mar 20 2017, 12:41 PM

To get commit access, please see http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
Someone should have tested this on _WIN32.

marsupial updated this revision to Diff 96287.Apr 22 2017, 11:01 AM
marsupial edited the summary of this revision. (Show Details)

Rebase to master

This revision was automatically updated to reflect the committed changes.
marsupial updated this revision to Diff 96488.Apr 24 2017, 5:55 PM
marsupial retitled this revision from Implement emulated TLS on Windows. to [builtins] Implement emulated TLS on Windows..
marsupial edited the summary of this revision. (Show Details)
marsupial added a reviewer: hans.

Only define atomic operations when not built with clang & compiler-rt.

marsupial reopened this revision.Apr 24 2017, 5:55 PM
This revision is now accepted and ready to land.Apr 24 2017, 5:55 PM
hans added inline comments.Apr 25 2017, 9:31 AM
lib/builtins/emutls.c
204 ↗(On Diff #96488)

It's not about compiler-rt; Clang defines __ATOMIC_ACQUIRE et al. as built-in macros: https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-builtins

Same thing with the __atomic_load_n and store_n functions.

GCC also provides these macros and functions. Probably it's better to just guard on #if !defined(__ATOMIC_RELEASE).

But shouldn't you also define the macros in a compatible way? I.e. shouldn't __ATOMIC_ACQUIRE be 2 and _RELEASE be 3? With your enum they'll be 0 and 1.

marsupial updated this revision to Diff 96596.Apr 25 2017, 10:25 AM
hans accepted this revision.Apr 25 2017, 10:27 AM

That should do it :-)

marsupial marked an inline comment as done.Apr 25 2017, 10:30 AM
marsupial added inline comments.
lib/builtins/emutls.c
204 ↗(On Diff #96488)

I'm not sure matching the enum values is that important as each function is used once.
But updated them as I was already changing the ifdef & comment.

This revision was automatically updated to reflect the committed changes.
marsupial marked an inline comment as done.
mstorsjo added inline comments.
compiler-rt/trunk/lib/builtins/emutls.c
105

Was there any specific reason for including immintrin.h here? I don't see anything below that would require it. It breaks cross compilation for windows on non-x86 architectures (ARM), and simply skipping the include fixes the build, so I don't think it's needed on x86 either?

marsupial added inline comments.Jul 30 2017, 10:01 PM
compiler-rt/trunk/lib/builtins/emutls.c
105

It's for the atomic load/store operations arround line 200.

mstorsjo added inline comments.Jul 30 2017, 11:18 PM
compiler-rt/trunk/lib/builtins/emutls.c
105

I see - thanks for clarifying!