search for: llvm_enable_threading

I'm not sure what LLVM_ENABLE_THREADS impacts - whether it is LLVM executables themselves or LLVM-generated code - but it seems to be on by default on the Windows CMake build (I'm building LLVM+Clang at trunk head using CMake/Visual Studio 2013 Win64). But 3 unit tests in IR, which are compiled only if define LLVM_ENABLE_THREADS is set, fail if LLVM_ENABLE_THEADS=ON:

On Apr 12, 2020, at 2:23 PM, Eli Friedman <efriedma at quicinc.com> wrote: > > Yes, the llvm::Smart* family of locks still exist. But very few places are using them outside of MLIR; it’s more common to just use plain std::mutex. > > That said, I don’t think it’s really a good idea to use them, even if they were fixed to work as designed. It’s not composable: the boolean

OK, sounds like we're screwed. There's two options: 1. Revert and give up on C++11 threading libraries for now. 2. Do what Eric suggests. Move all the mutex usage under #ifdef LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported. Do people have objections to 2? I don't really like it either. On Fri, Jun

Sorry, I mean only disable this for THREADS-WIN32, not threads-posix. On Fri, Jun 20, 2014 at 11:14 AM, Zachary Turner <zturner at google.com> wrote: > #2 is better if we can detect threads-win32 vs threads-posix on MinGW, and > only disable this for threads-posix. We can check for > _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if > there's a better

Hi all, I was looking at the profile for a tool I’m working on, and noticed that it is spending 10% of its time doing locking related stuff. The structure of the tool is that it reading in a ton of stuff (e.g. one moderate example I’m working with is 40M of input) into MLIR, then uses its multithreaded pass manager to do transformations. As it happens, the structure of this is that the parsing

Manish Verma <manish.avtaar at gmail.com> writes: > I am attaching a patch which fixes the above mentioned failures. Could you > please review the patch? [snip] > index 79eb098..6419653 100644 > --- a/unittests/Support/ManagedStatic.cpp > +++ b/unittests/Support/ManagedStatic.cpp > @@ -9,7 +9,7 @@ > #include "llvm/Support/ManagedStatic.h" > #include

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

Hi llvm-dev, Our code base has a ancient copy of llvm (ver 3.5.1), and it uses the LLVM code gen for some domain-specific language. The previous dev left a global lock around the usage of LLVM code gen stating that because LLVM code gen can only be accessed single-threaded it needs to be protected with this global lock. But now this lock has caused some perf issues as we pretty much lose

+chandlerc, aaronballman, in case there are additional carryovers and/or issues from the review thread which I've left out. I have a patch up for review[1, 2] that attempts to replace LLVM's mutex implementation with std::mutex and std::recursive_mutex. While the patch seems to work, there are questions surrounding whether or not the approach used is correct. I'll try to summarize

Thank you Johannes, I looked it up and it seems that we're creating one LLVMContext per compilation "unit", not sure if that matters. i.e. there's no single globally shared LLVMContext object. Is LLVMContext *the* concurrency isolation (or unit) here? On Wed, Apr 3, 2019 at 6:34 PM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > Do you use one llvm context or one

It sounds like this version of libstdc++ doesn't support std::recursive_mutex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives. Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld

Hi, I'm making my way through the WritingAnLLVMPass tutorial and hitting the following issue. $ opt -load ../../../Debug+Asserts/lib/LLVMHello.so -hello < hello.bc > /dev/null opt: symbol lookup error: ../../../Debug+Asserts/lib/LLVMHello.so: undefined symbol: AnnotateHappensAfter nm -g ../../../Debug+Asserts/lib/LLVMHello.so U AnnotateHappensAfter ... $ ldd

...is always held back by the compilers and standard libraries that they actually use in practice. We say LLVM requires C++11 which mandates a working set of threading primitives, but in practice those don't exist on some platforms that people would like us to support, so we end up maintaining the LLVM_ENABLE_THREADING=0 build for them. It seems more practical to simply list the minimum versions of supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc. On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>...

...is always held back by the compilers and standard libraries that they actually use in practice. We say LLVM requires C++11 which mandates a working set of threading primitives, but in practice those don't exist on some platforms that people would like us to support, so we end up maintaining the LLVM_ENABLE_THREADING=0 build for them. It seems more practical to simply list the minimum versions of supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc. On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org<m...

...t; the compilers and standard libraries that they actually use in practice. We > say LLVM requires C++11 which mandates a working set of threading > primitives, but in practice those don't exist on some platforms that people > would like us to support, so we end up maintaining the > LLVM_ENABLE_THREADING=0 build for them. > > It seems more practical to simply list the minimum versions of supported > toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang > 3.N, libc++ 3.N, libstdc++ 3.N, etc. > > On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev < &g...

...is always held back by the compilers and standard libraries that they actually use in practice. We say LLVM requires C++11 which mandates a working set of threading primitives, but in practice those don't exist on some platforms that people would like us to support, so we end up maintaining the LLVM_ENABLE_THREADING=0 build for them. > > It seems more practical to simply list the minimum versions of supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc. > > On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev <llvm-dev...

...is always held back by the compilers and standard libraries that they actually use in practice. We say LLVM requires C++11 which mandates a working set of threading primitives, but in practice those don't exist on some platforms that people would like us to support, so we end up maintaining the LLVM_ENABLE_THREADING=0 build for them. >> >> It seems more practical to simply list the minimum versions of supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc. >> >> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-d...

...and standard libraries that they actually use in practice. We >> say LLVM requires C++11 which mandates a working set of threading >> primitives, but in practice those don't exist on some platforms that people >> would like us to support, so we end up maintaining the >> LLVM_ENABLE_THREADING=0 build for them. >> >> It seems more practical to simply list the minimum versions of supported >> toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang >> 3.N, libc++ 3.N, libstdc++ 3.N, etc. >> >> On Thu, May 10, 2018 at 11:36 AM Zachary Tur...

...is always held back by the compilers and standard libraries that they actually use in practice. We say LLVM requires C++11 which mandates a working set of threading primitives, but in practice those don't exist on some platforms that people would like us to support, so we end up maintaining the LLVM_ENABLE_THREADING=0 build for them. >> >> It seems more practical to simply list the minimum versions of supported toolchains that are commonly used to build, i.e. GCC 5, MSVC 2015, Clang 3.N, libc++ 3.N, libstdc++ 3.N, etc. >> >> On Thu, May 10, 2018 at 11:36 AM Zachary Turner via llvm-dev...

On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with