Commit Graph

48 Commits

Author SHA1 Message Date
Alexandre Ganea 8404aeb56a [Support] On Windows, ensure hardware_concurrency() extends to all CPU sockets and all NUMA groups
The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket.

== Background ==
Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads.

By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to.

This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market.

== The problem ==
The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std:🧵:hardware_concurrency() -- which can only return processors from the current "processor group".

== The changes in this patch ==
To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO).

When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead.
The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used.

When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once.

Differential Revision: https://reviews.llvm.org/D71775
2020-02-14 10:24:22 -05:00
Sam McCall a9c3c176ad Reland "[Support] Add a way to run a function on a detached thread""
This reverts commit 7bc7fe6b78.
The immediate callers have been fixed to pass nullopt where appropriate.
2019-10-23 15:51:44 +02:00
Sam McCall 7bc7fe6b78 Revert "[Support] Add a way to run a function on a detached thread"
This reverts commit 40668abca4.
This causes clang tests to fail, as stacksize=0 is being explicitly passed and
is no longer a no-op.
2019-10-23 15:10:35 +02:00
Sam McCall 40668abca4 [Support] Add a way to run a function on a detached thread
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
2019-10-23 12:48:38 +02:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Nico Weber 712e8d29c4 s/LLVM_ON_WIN32/_WIN32/, llvm
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
2018-04-29 00:45:03 +00:00
Rafael Espindola 8c0ff9508d Bring r314809 back.
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:🧵:hardware_concurrency.

The issue with std:🧵: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
2017-10-04 20:27:01 +00:00
Daniel Neilson bef94bcbae Revert D38481 due to missing cmake check for CPU_COUNT
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
2017-10-04 18:19:03 +00:00
Rafael Espindola 6e182fbab4 Use sched_getaffinity instead of std:🧵:hardware_concurrency.
The issue with std:🧵: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
2017-10-03 16:25:15 +00:00
Zachary Turner 1f004c43d2 Try to fix thread name truncation on non-Windows.
llvm-svn: 296976
2017-03-04 18:53:09 +00:00
Zachary Turner 640cee0d2d Fix Threading path when LLVM_ENABLE_THREADS=0.
llvm-svn: 296914
2017-03-03 21:49:38 +00:00
Zachary Turner 91db01fa6c Don't bring in llvm/Support/thread.h in Threading.cpp
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
2017-03-03 17:39:24 +00:00
Zachary Turner 757dbc9ff3 [Support] Provide access to current thread name/thread id.
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
2017-03-03 17:15:17 +00:00
Teresa Johnson c0ef9e4316 Rename interface for querying physical hardware concurrency
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
2016-10-17 14:56:53 +00:00
Mehdi Amini f8fd20402a hardware_physical_concurrency() should return 1 when LLVM is built with LLVM_ENABLE_THREADS=OFF
llvm-svn: 284283
2016-10-14 21:32:35 +00:00
Teresa Johnson 2bd812c5dc Add interface for querying physical hardware concurrency
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
2016-10-14 00:13:59 +00:00
Chandler Carruth fe1ffb912d [LPM] Reinstate r271781 which reinstated r271652 to replace the
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
2016-06-04 19:57:55 +00:00
Chandler Carruth fe9466fe2c [LPM] Revert r271781 which was a re-commit of r271652.
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
2016-06-04 09:36:40 +00:00
Chandler Carruth fa4890e068 [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:
----
[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
2016-06-04 07:25:44 +00:00
Chandler Carruth d6c5bc2c81 Fix the use of sys::MemoryFence after including WindowsSupport.h that
r271558 introduced.

llvm-svn: 271563
2016-06-02 18:42:23 +00:00
Chandler Carruth dd1463823a This is yet another attempt to re-instate r220932 as discussed in
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
2016-06-02 18:22:12 +00:00
Mehdi Amini 0fb2488702 Revert "Revert "Revert 220932.": "Removing the static initializer in 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
2016-05-14 23:44:21 +00:00
Mehdi Amini c048b6c4cd Revert "Revert 220932.": "Removing the static initializer in 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
2016-05-14 20:55:52 +00:00
Jiangning Liu 1fb71bc395 Revert 220932.
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
2014-11-05 04:44:31 +00:00
Chris Bieneman 14e2bcccfb Removing the static initializer in ManagedStatic.cpp by using llvm_call_once 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
2014-10-30 22:07:09 +00:00
Chandler Carruth 39cd216f8f Re-apply r211287: Remove support for LLVM runtime multi-threading.
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
2014-06-27 15:13:01 +00:00
NAKAMURA Takumi 104e5f67e2 Revert r211287, "Remove support for LLVM runtime multi-threading."
libclang still requires it on cygming, lack of incomplete <mutex>.

llvm-svn: 211592
2014-06-24 13:36:31 +00:00
Zachary Turner 9c9710eaf4 Remove support for LLVM runtime multi-threading.
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
2014-06-19 18:18:23 +00:00
Zachary Turner 6ad2444d5b Kill the LLVM global lock.
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
2014-06-19 16:17:42 +00:00
Zachary Turner ccbf3d01f0 Revert r211066, 211067, 211068, 211069, 211070.
These were committed accidentally from the wrong branch before having
a review sign-off.

llvm-svn: 211072
2014-06-16 22:49:41 +00:00
Zachary Turner 89ae856c46 Kill the LLVM global lock.
llvm-svn: 211069
2014-06-16 22:40:42 +00:00
Zachary Turner 0f2c641f86 Remove some more code out into a separate CL.
llvm-svn: 211067
2014-06-16 22:40:17 +00:00
Zachary Turner b344f057d0 Users of the llvm global mutex must now acquire it manually.
This allows the mutex to be acquired in a guarded, RAII fashion.

llvm-svn: 211066
2014-06-16 22:39:38 +00:00
Zachary Turner 6610b99cb5 Revert "Remove support for runtime multi-threading."
This reverts revision r210600.

llvm-svn: 210603
2014-06-10 23:15:43 +00:00
Zachary Turner f6054ca18c Remove support for runtime multi-threading.
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
2014-06-10 23:01:20 +00:00
Craig Topper c10719f55d [C++11] Make use of 'nullptr' in the Support library.
llvm-svn: 205697
2014-04-07 04:17:22 +00:00
Benjamin Kramer 17388a61b2 Revert "[C++11] Replace LLVM atomics with std::atomic."
Breaks the MSVC build.
DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list

llvm-svn: 202731
2014-03-03 18:02:34 +00:00
Benjamin Kramer 0b6eb591a4 [C++11] Replace LLVM atomics with std::atomic.
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
2014-03-03 17:53:30 +00:00
Reid Kleckner d59e2faae1 Rename Windows.h to WindowsSupport.h to avoid ambiguity
llvm-svn: 201258
2014-02-12 21:26:20 +00:00
Chandler Carruth ed0881b2a6 Use the new script to sort the includes of every file under lib.
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
2012-12-03 16:50:05 +00:00
Dylan Noblesmith efddf20126 rename ENABLE_THREADS to LLVM_ENABLE_THREADS
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
2011-11-28 00:48:58 +00:00
Eric Christopher 4418a60272 Rename LLVM_MULTITHREADED define and fix build without threads.
Patch by Arrowdodger.

llvm-svn: 140064
2011-09-19 20:43:23 +00:00
NAKAMURA Takumi dbd883b915 Add Win32 support to llvm::llvm_execute_on_thread(). Thanks to Aaron Ballman!
llvm-svn: 140011
2011-09-19 07:41:43 +00:00
Charles Davis 54c9eb6fff Now to chant the magical incantation that will exorcise the System library
from LLVM forever:

grep -lR "llvm/System" * | grep -v .svn | xargs sed -ie 's#llvm/System#llvm/Support#g'

llvm-svn: 120314
2010-11-29 19:44:50 +00:00
Michael J. Spencer 447762da85 Merge System into Support.
llvm-svn: 120298
2010-11-29 18:16:10 +00:00
Owen Anderson 7d42b95b6c Move Threading.[h|cpp] from Support to System.
llvm-svn: 73707
2009-06-18 16:54:52 +00:00
Owen Anderson 993e4261d0 Add newline at end of file.
llvm-svn: 73551
2009-06-16 20:53:09 +00:00
Owen Anderson 4cb4b6191a Split the thread-related APIs out into their own file, and add a few more
calls for convenience.

llvm-svn: 73512
2009-06-16 17:33:51 +00:00