Page MenuHomePhabricator

libcxx: Move Windows threading support into a .cpp file.
ClosedPublic

Authored by pcc on Jan 17 2018, 4:35 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jan 17 2018, 4:35 PM

Sounds like a great idea! This would avoid e.g. this issue I've recently run into (and worked around): https://codereview.qt-project.org/216903

smeenai requested changes to this revision.Jan 18 2018, 6:14 PM

This prevents inlining, which might not be great. I'd be happier if we kept everything in the header but just forward declared whatever we needed from the Windows headers rather than actually including them (I've been meaning to do that for a while, just haven't gotten the chance to work on it yet).

Also, IIRC, a CRITICAL_SECTION is actually a 40-byte sized struct, so replacing CRITICAL_SECTION with void * is gonna cause issues.

This revision now requires changes to proceed.Jan 18 2018, 6:14 PM
pcc added a comment.Jan 18 2018, 6:24 PM

This prevents inlining, which might not be great.

It doesn't seem like a big problem to me. Many of these APIs will result in system calls, and the cost of not inlining is probably dwarfed by the cost of the system call.

Also, IIRC, a CRITICAL_SECTION is actually a 40-byte sized struct, so replacing CRITICAL_SECTION with void * is gonna cause issues.

So it is. I'll fix that.

It doesn't seem like a big problem to me. Many of these APIs will result in system calls, and the cost of not inlining is probably dwarfed by the cost of the system call.

They'll only cause system calls in case of contention, right? SRWLock in particular is supposed to be super lightweight. I agree that it's probably not a huge deal in practice, but it seems like if you already have to provide some fake types to make the header happy, you might as well go all the way with your own prototypes.

With that said, I'd be fine with this patch as-is (once the critical section issue is fixed); we can always restore the inlining later whenever someone gets the time/if it does turn out to be an issue. libc++ on Windows will miss out on lots of inlining opportunities because of dllimport anyway (clang doesn't inline a dllimport function if it calls a non-dllimport function, which pessimizes lots of libc++ dllimport functions which call trivial non-dllimport helpers, e.g. basic_string::data calling _VSTD::__to_raw_pointer), so there are bigger problems already.

pcc updated this revision to Diff 130731.Jan 19 2018, 5:25 PM
  • Add compatible definitions of __libcpp_recursive_mutex_t
mstorsjo added inline comments.Jan 20 2018, 4:08 AM
libcxx/include/__threading_support
87 ↗(On Diff #130731)

|| defined(_M_ARM64) here as well - there, it has the same size (40 bytes) as on x86_64.

mstorsjo added inline comments.Jan 20 2018, 9:49 AM
libcxx/include/__threading_support
87 ↗(On Diff #130731)

Oh, also - please add checks for corresponding GCC defines, to keep things working for clang in mingw mode. (__aarch64__ etc)

pcc updated this revision to Diff 130952.Jan 22 2018, 1:19 PM
pcc marked 2 inline comments as done.
  • Add some more defined checks

LGTM now, but I'll let @smeenai give it the proper approval.

smeenai accepted this revision.Jan 22 2018, 5:51 PM

LGTM.

libcxx/src/support/win32/thread_win32.cpp
18–39 ↗(On Diff #130952)

Awesome.

This revision is now accepted and ready to land.Jan 22 2018, 5:51 PM
This revision was automatically updated to reflect the committed changes.
eastig added a subscriber: eastig.Jan 24 2018, 2:41 AM

Hi Peter,

We have libcxx-externally-threaded-x86 failing due to the changes:

$ cmake ../llvm -DCMAKE_BUILD_TYPE=MinSizeRel -DCMAKE_C_COMPILER=/work/clang-3.9/bin/clang -DCMAKE_CXX_COMPILER=/work/clang-3.9/bin/clang++ -DLLVM_ENABLE_ASSERTIONS=ON -DLIBCXX_ENABLE_ASSERTIONS=ON -DLIBCXXABI_USE_LLVM_UNWINDER=ON -DLLVM_LIT_ARGS=-sv -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_SHARED=OFF -DLIBUNWIND_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC_UNWINDER=ON -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY=ON -DLIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY=ON -G Ninja
...
$ ninja -j32 cxxabi
...
/work/clang-3.9/bin/clang++   -DHAVE___CXA_THREAD_ATEXIT_IMPL -DLIBCXXABI_USE_LLVM_UNWINDER -D_DEBUG -D_GNU_SOURCE -D_LIBCPP_DISABLE_EXTERN_TEMPLATE -D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL -D_LIBCXXABI_BUILDING_LIBRARY -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/libcxxabi/src -I/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxxabi/src -I/usr/include/libxml2 -Iinclude -I/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/include -I/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxxabi/include -I/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libunwind/include -I/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxx/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections  -Os  -fPIC   -UNDEBUG -nostdinc++ -Werror=return-type -W -Wall -Wchar-subscripts -Wconversion -Wmismatched-tags -Wmissing-braces -Wnewline-eof -Wunused-function -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef -Wno-error -pedantic -fstrict-aliasing -funwind-tables -D_DEBUG -D_LIBCPP_BUILD_STATIC -std=c++11 -MD -MT projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_guard.cpp.o -MF projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_guard.cpp.o.d -o projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_guard.cpp.o -c /work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxxabi/src/cxa_guard.cpp
In file included from /work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxxabi/src/cxa_guard.cpp:13:
/work/llvm-test/slave/libcxx-externally-threaded-x86/llvm/projects/libcxx/include/__threading_support:117:35: error: unknown type name '__libcpp_recursive_mutex_t'
int __libcpp_recursive_mutex_init(__libcpp_recursive_mutex_t *__m);
...

You can see we use Clang 3.9.
Any idea how to fix it?

Thanks,
Evgeny Astigeevich

pcc added a comment.Jan 24 2018, 1:52 PM

Hi Peter,

We have libcxx-externally-threaded-x86 failing due to the changes:

I think this should be fixed by D42503.