search for: llvm_enable_thread

Displaying 20 results from an estimated 28 matches for "llvm_enable_thread".

Did you mean: llvm_enable_threads
2015 Apr 04
3
[LLVMdev] LLVM_ENABLE_THREADING=ON by default in Windows, is this right?
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...
2020 Apr 12
3
LLVM multithreading support
...uently called code, or using a better lock implementation). > If you want some mechanism to disable MLIR locking, it should probably be a boolean attached to the MLIR context in question, not a global variable. > Ok, but let me argue the other way. We currently have a cmake flag that sets LLVM_ENABLE_THREADS, and that flag enables an across the board speedup. That cmake flag is the *worst* possible thing for library composability. :-). Are you suggesting that we remove it? -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...
2014 Jun 20
4
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
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 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > The whole "mutex&q...
2014 Jun 20
3
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
...1:09 AM, Reid Kleckner <rnk at google.com> wrote: > >> 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 20, 2014 at 10:33 AM, Yaron Keren <yaron.keren at...
2020 Apr 12
7
LLVM multithreading support
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
2013 Jan 08
0
[LLVMdev] Build failure when building single threaded LLVM with CMake
...nittests/Support/ManagedStatic.cpp > +++ b/unittests/Support/ManagedStatic.cpp > @@ -9,7 +9,7 @@ > #include "llvm/Support/ManagedStatic.h" > #include "llvm/Config/config.h" > #include "llvm/Support/Threading.h" > -#ifdef HAVE_PTHREAD_H > +#ifdef LLVM_ENABLE_THREADS !=0 && defined(HAVE_PTHREAD_H) Use #if instead of #ifdef > #include <pthread.h> > #endif > > @@ -19,7 +19,7 @@ using namespace llvm; > > namespace { > > -#ifdef HAVE_PTHREAD_H > +#ifdef LLVM_ENABLE_PTHREADS!=0 && defined(HAVE_PTHREAD_H)...
2013 Jan 07
2
[LLVMdev] Build failure when building single threaded LLVM with CMake
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 `testing::internal::ThreadLocal<testing::TestPartResultReporterInterface*>::~ThreadLocal()': gtest.cc:(.text._ZN7testing8internal11ThreadLocalIPNS_31TestPartResultReporterInterfaceEED2E...
2019 Apr 04
2
single-threaded code-gen and how to make it support multi-thread
...e protected with this global lock. But now this lock has caused some perf issues as we pretty much lose concurrency when having to compile a large number of source files. I've tried to remove the global lock and what I have observed in crashing stack is something like below: (I did make sure LLVM_ENABLE_THREADS is defined to be 1, apparently it didn't seem to help) The document around this seems vague, I have not found a clear instruction as to how to solve this, hence this post. Can anyone help with some pointers? Any guidance is appreciated:) ntdll.dll!RtlReportCriticalFailure(long StatusCode,...
2014 Jun 07
5
[LLVMdev] Multi-threading and mutexes in LLVM
...9;ll try to summarize the issues as best I can, in hopes of getting some feedback from a broader audience, to make sure this is done correctly: 1) Should support multi-threading be a compile-time or runtime parameter in LLVM? Currently it is both. It is compile-time through the use of the define LLVM_ENABLE_THREADS, and it is runtime through the use of functions llvm_start_multithreaded, llvm_is_multithreaded, etc. I and some others feel like runtime support for multi-threading could be removed, and it should be compile-time only. However, I am not aware of all the ways in which this is being used, so this...
2019 Apr 04
2
single-threaded code-gen and how to make it support multi-thread
...t; > But now this lock has caused some perf issues as we pretty much lose > concurrency when having to compile a large number of source files. > > I've tried to remove the global lock and what I have observed in crashing > stack is something like below: > > (I did make sure LLVM_ENABLE_THREADS is defined to be 1, apparently it > didn't seem to help) > > The document around this seems vague, I have not found a clear instruction > as to how to solve this, hence this post. Can anyone help with some > pointers? > > Any guidance is appreciated:) > > ntdll.dll...
2014 Jun 20
3
[LLVMdev] [PATCH] Replace the Execution Engine's mutex with std::recursive_mutex
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
2014 Jul 09
2
[LLVMdev] Help with the 'WritingAnLLVMPass' tutorial
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
2018 May 10
0
Using C++14 code in LLVM
...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&...
2018 May 10
2
Using C++14 code in LLVM
...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&l...
2018 May 10
8
Using C++14 code in LLVM
...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 <...
2018 May 10
0
Using C++14 code in LLVM
...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-d...
2018 May 10
0
Using C++14 code in LLVM
...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 llv...
2018 May 10
1
Using C++14 code in LLVM
...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...
2018 May 11
0
Using C++14 code in LLVM
...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-...
2020 Apr 01
4
LLD issue on a massively parallel build machine
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 something like: > >&lt...