search for: llvm_enable_threads

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 i...

...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-...

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&qu...

...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...

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

...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) S...

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_31TestPartResultReporterInterfaceEED2Ev...

...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,...

...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...

...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!...

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

The easy way not to have a three year discussion is to not worry about it for another three years. :) So, I think we should take the easy things on the table and just move to C++14 in the near future. It's just a matter of dropping support for building on distros that only have GCC <5 (aka Trusty, which is from 2014 itself). Let's do that and call it a day. --- Aside: I'm always

Hi, IMHO, it’s a good idea to move to C++14 first. What do you think about doing this by two phases: Phase1: require GCC >= 5 but build in C++11 mode (this will give time to adapt build infrastructure to a new gcc) Phase2: switch to C++14 Thanks, Evgeny From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org>

Last time this came up, there were a lot of people that were stuck on GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most disruptive part of this, and I think that will really need a decent amount of time. =[ On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On May 10, 2018, at 12:25 PM, Evgeny Astigeevich

> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > IMHO, it’s a good idea to move to C++14 first. > > What do you think about doing this by two phases: > > Phase1: require GCC >= 5 but build in C++11 mode (this will give time to adapt build infrastructure to a new gcc) > Phase2: switch to

> On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at google.com> wrote: > > Last time this came up, there were a lot of people that were stuck on GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most disruptive part of this, and I think that will really need a decent amount of time. =[ Those people don’t build a browser? Because if they build

On Thu, May 10, 2018 at 3:06 PM JF Bastien <jfbastien at apple.com> wrote: > On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > Last time this came up, there were a lot of people that were stuck on GCC > 4.9 due to ABI reasons. I think forcing that upgrade is going to be the > most disruptive part of this, and I think that will

And what will be the lowest version of clang that will be supported for building? FreeBSD's oldest supported OS release is still stuck with clang 3.4 (and a corresponding copy of libc++), which has some support for C++14, although it's still called c++1y there, but probably not C++17. Also, it isn't exactly clear from which llvm/clang release C++17 is fully supported. -Dimitry >

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: > ><...