summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Threading.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-231-2/+49
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-231-49/+2
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-231-2/+49
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-2/+2
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* Bring r314809 back.Rafael Espindola2017-10-041-0/+14
| | | | | | | | | | | | | | | | | | | | | But now include a check for CPU_COUNT so we still build on 10 year old versions of glibc. Original message: Use sched_getaffinity instead of std::thread::hardware_concurrency. The issue with std::thread::hardware_concurrency is that it forwards to libc and some implementations (like glibc) don't take thread affinity into consideration. With this change a llvm program that can execute in only 2 cores will use 2 threads, even if the machine has 32 cores. This makes benchmarking a lot easier, but should also help if someone doesn't want to use all cores for compilation for example. llvm-svn: 314931
* Revert D38481 due to missing cmake check for CPU_COUNTDaniel Neilson2017-10-041-14/+0
| | | | | | | | | | | | | Summary: This reverts D38481. The change breaks systems with older versions of glibc. It injects a use of CPU_COUNT() from sched.h without checking to ensure that the function exists first. Reviewers: Subscribers: llvm-svn: 314922
* Use sched_getaffinity instead of std::thread::hardware_concurrency.Rafael Espindola2017-10-031-0/+14
| | | | | | | | | | | | | | The issue with std::thread::hardware_concurrency is that it forwards to libc and some implementations (like glibc) don't take thread affinity into consideration. With this change a llvm program that can execute in only 2 cores will use 2 threads, even if the machine has 32 cores. This makes benchmarking a lot easier, but should also help if someone doesn't want to use all cores for compilation for example. llvm-svn: 314809
* Try to fix thread name truncation on non-Windows.Zachary Turner2017-03-041-0/+2
| | | | llvm-svn: 296976
* Fix Threading path when LLVM_ENABLE_THREADS=0.Zachary Turner2017-03-031-1/+1
| | | | llvm-svn: 296914
* Don't bring in llvm/Support/thread.h in Threading.cppZachary Turner2017-03-031-2/+8
| | | | | | | | | | | | Doing so defines the type llvm::thread. On FreeBSD, we need to call a macro which references its own ::thread type, which causes an ambiguity due to ADL when inside of the llvm namespace. Since we don't even need this unless LLVM_ENABLE_THREADS == 1, we don't even need this type anyway, as it is always equal to std::thread, so we can just use that directly. llvm-svn: 296891
* [Support] Provide access to current thread name/thread id.Zachary Turner2017-03-031-84/+29
| | | | | | | | | | | | | | | | Applications often need the current thread id when making system calls, and some operating systems provide the notion of a thread name, which can be useful in enabling better diagnostics when debugging or logging. This patch adds an accessor for the thread id, and "best effort" getters and setters for the thread name. Since this is non critical functionality, no error is returned to indicate that a platform doesn't support thread names. Differential Revision: https://reviews.llvm.org/D30526 llvm-svn: 296887
* Rename interface for querying physical hardware concurrencyTeresa Johnson2016-10-171-1/+1
| | | | | | | | | | Based on post-commit review for D25585/r284180, rename hardware_physical_concurrency to heavyweight_hardware_concurrency, to better reflect what type of tasks it should be used for and to enable other systems to map this to something other than the number of physical cores. llvm-svn: 284390
* hardware_physical_concurrency() should return 1 when LLVM is built with ↵Mehdi Amini2016-10-141-0/+3
| | | | | | LLVM_ENABLE_THREADS=OFF llvm-svn: 284283
* Add interface for querying physical hardware concurrencyTeresa Johnson2016-10-141-0/+8
| | | | | | | | | | | | | | | | | | | | Summary: This will be used by ThinLTO to set the amount of backend parallelism, which performs better when restricted to the number of physical cores (on X86 at least, where getHostNumPhysicalCores is currently defined). If not available this falls back to thread::hardware_concurrency. Note I didn't add to the thread class since that is a typedef to std::thread where available. Reviewers: mehdi_amini Subscribers: beanz, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D25585 llvm-svn: 284180
* [LPM] Reinstate r271781 which reinstated r271652 to replace theChandler Carruth2016-06-041-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CALL_ONCE_... macro in the legacy pass manager with the new llvm::call_once facility. Nothing changed sicne the last attempt in r271781 which I reverted in r271788. At least one of the failures I saw was spurious, and I want to make sure the other failures are real before I work around them -- they appeared to only effect ppc64le and ppc64be. Original commit message of r271781: ---- [LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy pass manager with the new llvm::call_once facility. This reverts commit r271657 and re-applies r271652 with a fix to actually work with arguments. In the original version, we just ended up directly calling std::call_once via ADL because of the std::once_flag argument. The llvm::call_once never worked with arguments. Now, llvm::call_once is a variadic template that perfectly forwards everything. As a part of this it had to move to the header and we use a generic functor rather than an explict function pointer. It would be nice to use std::invoke here but we don't have it yet. That means pointer to members won't work here, but that seems a tolerable compromise. I've also tested this by forcing the fallback path, so hopefully it sticks this time. ---- Original commit message of r271652: ---- [LPM] Replace the CALL_ONCE_... macro in the legacy pass manager with the new llvm::call_once facility. This facility matches the standard APIs and when the platform supports it actually directly uses the standard provided functionality. This is both more efficient on some platforms and much more TSan friendly. The only remaining user of the cas_flag and home-rolled atomics is the fallback implementation of call_once. I have a patch that removes them entirely, but it needs a Windows patch to land first. This alone substantially cleans up the macros for the legacy pass manager, and should subsume some of the work Mehdi was doing to clear the path for TSan testing of ThinLTO, a really important step to have reliable upstream testing of ThinLTO in all forms. ---- llvm-svn: 271800
* [LPM] Revert r271781 which was a re-commit of r271652.Chandler Carruth2016-06-041-0/+27
| | | | | | | | | | | | There appears to be a strange exception thrown and crash using call_once on a PPC build bot, and a *really* weird windows link error for GCMetadata.obj. Still need to investigate the cause of both problems. Original change summary: [LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacy pass manager with the new llvm::call_once facility. llvm-svn: 271788
* [LPM] Reinstate r271652 to replace the CALL_ONCE_... macro in the legacyChandler Carruth2016-06-041-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pass manager with the new llvm::call_once facility. This reverts commit r271657 and re-applies r271652 with a fix to actually work with arguments. In the original version, we just ended up directly calling std::call_once via ADL because of the std::once_flag argument. The llvm::call_once never worked with arguments. Now, llvm::call_once is a variadic template that perfectly forwards everything. As a part of this it had to move to the header and we use a generic functor rather than an explict function pointer. It would be nice to use std::invoke here but we don't have it yet. That means pointer to members won't work here, but that seems a tolerable compromise. I've also tested this by forcing the fallback path, so hopefully it sticks this time. Original commit message: ---- [LPM] Replace the CALL_ONCE_... macro in the legacy pass manager with the new llvm::call_once facility. This facility matches the standard APIs and when the platform supports it actually directly uses the standard provided functionality. This is both more efficient on some platforms and much more TSan friendly. The only remaining user of the cas_flag and home-rolled atomics is the fallback implementation of call_once. I have a patch that removes them entirely, but it needs a Windows patch to land first. This alone substantially cleans up the macros for the legacy pass manager, and should subsume some of the work Mehdi was doing to clear the path for TSan testing of ThinLTO, a really important step to have reliable upstream testing of ThinLTO in all forms. llvm-svn: 271781
* Fix the use of sys::MemoryFence after including WindowsSupport.h thatChandler Carruth2016-06-021-0/+5
| | | | | | r271558 introduced. llvm-svn: 271563
* This is yet another attempt to re-instate r220932 as discussed inChandler Carruth2016-06-021-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D19271. Previous attempt was broken by NetBSD, so in this version I've made the fallback path generic rather than Windows specific and sent both Windows and NetBSD to it. I've also re-formatted the code some, and used an exact clone of the code in PassSupport.h for doing manual call-once using our atomics rather than rolling a new one. If this sticks, we can replace the fallback path for Windows with a Windows-specific implementation that is more reliable. Original commit message: This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once. These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once. Differential Revision: http://reviews.llvm.org/D5922 llvm-svn: 271558
* Revert "Revert "Revert 220932.": "Removing the static initializer in ↵Mehdi Amini2016-05-141-7/+0
| | | | | | | | | | ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex"" This reverts commit r269577. Broke NetBSD, waiting for Kamil to investigate From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269584
* Revert "Revert 220932.": "Removing the static initializer in ↵Mehdi Amini2016-05-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex" This reverts commit r221331 and reinstate r220932 as discussed in D19271. Original commit message was: This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once. These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once. Differential Revision: http://reviews.llvm.org/D5922 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 269577
* Revert 220932.Jiangning Liu2014-11-051-7/+0
| | | | | | | | | Commit 220932 caused crash when building clang-tblgen on aarch64 debian target, so it's blocking all daily tests. The std::call_once implementation in pthread has bug for aarch64 debian. llvm-svn: 221331
* Removing the static initializer in ManagedStatic.cpp by using llvm_call_once ↵Chris Bieneman2014-10-301-0/+7
| | | | | | | | | | | | | | | | | | | to initialize the ManagedStatic mutex. Summary: This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once. These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once. Reviewers: aaron.ballman, chapuni, chandlerc, rnk Reviewed By: rnk Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D5922 llvm-svn: 220932
* Re-apply r211287: Remove support for LLVM runtime multi-threading.Chandler Carruth2014-06-271-26/+3
| | | | | | | I'll fix the problems in libclang and other projects in ways that don't require <mutex> until we sort out the cygwin situation. llvm-svn: 211900
* Revert r211287, "Remove support for LLVM runtime multi-threading."NAKAMURA Takumi2014-06-241-3/+26
| | | | | | libclang still requires it on cygming, lack of incomplete <mutex>. llvm-svn: 211592
* Remove support for LLVM runtime multi-threading.Zachary Turner2014-06-191-26/+3
| | | | | | | | | | | | | After a number of previous small iterations, the functions llvm_start_multithreaded() and llvm_stop_multithreaded() have been reduced essentially to no-ops. This change removes them entirely. Reviewed by: rnk, dblaikie Differential Revision: http://reviews.llvm.org/D4216 llvm-svn: 211287
* Kill the LLVM global lock.Zachary Turner2014-06-191-12/+0
| | | | | | | | | | | | | | This patch removes the LLVM global lock, and updates all existing users of the global lock to use their own mutex. None of the existing users of the global lock were protecting code that was mutually exclusive with any of the other users of the global lock, so its purpose was not being met. Reviewed by: rnk Differential Revision: http://reviews.llvm.org/D4142 llvm-svn: 211277
* Revert r211066, 211067, 211068, 211069, 211070.Zachary Turner2014-06-161-3/+38
| | | | | | | These were committed accidentally from the wrong branch before having a review sign-off. llvm-svn: 211072
* Kill the LLVM global lock.Zachary Turner2014-06-161-5/+0
| | | | llvm-svn: 211069
* Remove some more code out into a separate CL.Zachary Turner2014-06-161-26/+3
| | | | llvm-svn: 211067
* Users of the llvm global mutex must now acquire it manually.Zachary Turner2014-06-161-11/+4
| | | | | | This allows the mutex to be acquired in a guarded, RAII fashion. llvm-svn: 211066
* Revert "Remove support for runtime multi-threading."Zachary Turner2014-06-101-5/+36
| | | | | | This reverts revision r210600. llvm-svn: 210603
* Remove support for runtime multi-threading.Zachary Turner2014-06-101-36/+5
| | | | | | | | | | | | | | | | | | | | | This patch removes the functions llvm_start_multithreaded() and llvm_stop_multithreaded(), and changes llvm_is_multithreaded() to return a constant value based on the value of the compile-time definition LLVM_ENABLE_THREADS. Previously, it was possible to have compile-time support for threads on, and runtime support for threads off, in which case certain mutexes were not allocated or ever acquired. Now, if the build is created with threads enabled, mutexes are always acquired. A test before/after patch of compiling a very large TU showed no noticeable performance impact of this change. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D4076 llvm-svn: 210600
* [C++11] Make use of 'nullptr' in the Support library.Craig Topper2014-04-071-3/+3
| | | | llvm-svn: 205697
* Revert "[C++11] Replace LLVM atomics with std::atomic."Benjamin Kramer2014-03-031-3/+3
| | | | | | | Breaks the MSVC build. DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list llvm-svn: 202731
* [C++11] Replace LLVM atomics with std::atomic.Benjamin Kramer2014-03-031-3/+3
| | | | | | | | | | | With C++11 we finally have a standardized way to specify atomic operations. Use them to replace the existing custom implemention. Sadly the translation is not entirely trivial as std::atomic allows more fine-grained control over the atomicity. I tried to preserve the old semantics as well as possible. Differential Revision: http://llvm-reviews.chandlerc.com/D2915 llvm-svn: 202730
* Rename Windows.h to WindowsSupport.h to avoid ambiguityReid Kleckner2014-02-121-1/+1
| | | | llvm-svn: 201258
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* rename ENABLE_THREADS to LLVM_ENABLE_THREADSDylan Noblesmith2011-11-281-4/+4
| | | | | | | | | | | Now that it needs to be exported in a public header (Valgrind.h) it should be prefixed to avoid collision with other projects. Add it to llvm-config.h as well. This'll require regenerating the configure script after this commit, but I don't have the required autoconf version. llvm-svn: 145214
* Rename LLVM_MULTITHREADED define and fix build without threads.Eric Christopher2011-09-191-4/+4
| | | | | | Patch by Arrowdodger. llvm-svn: 140064
* Add Win32 support to llvm::llvm_execute_on_thread(). Thanks to Aaron Ballman!NAKAMURA Takumi2011-09-191-2/+33
| | | | llvm-svn: 140011
* Now to chant the magical incantation that will exorcise the System libraryCharles Davis2010-11-291-1/+1
| | | | | | | | from LLVM forever: grep -lR "llvm/System" * | grep -v .svn | xargs sed -ie 's#llvm/System#llvm/Support#g' llvm-svn: 120314
* Merge System into Support.Michael J. Spencer2010-11-291-0/+116
| | | | llvm-svn: 120298
* Move Threading.[h|cpp] from Support to System.Owen Anderson2009-06-181-63/+0
| | | | llvm-svn: 73707
* Add newline at end of file.Owen Anderson2009-06-161-1/+1
| | | | llvm-svn: 73551
* Split the thread-related APIs out into their own file, and add a few moreOwen Anderson2009-06-161-0/+63
calls for convenience. llvm-svn: 73512
OpenPOWER on IntegriCloud