This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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
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 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.
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. |
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) |
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