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

[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

show more ...

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 ne

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

show more ...

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

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

show more ...

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

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

show more ...

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 chec

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

show more ...

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 thre

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

show more ...

Try to fix thread name truncation on non-Windows.

llvm-svn: 296976

Fix Threading path when LLVM_ENABLE_THREADS=0.

llvm-svn: 296914

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 d

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

show more ...

[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, whi

[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

show more ...

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 reflec

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

show more ...

hardware_physical_concurrency() should return 1 when LLVM is built with LLVM_ENABLE_THREADS=OFF

llvm-svn: 284283

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 physic

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

show more ...

[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 r27178

[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

show more ...

[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
GCMeta

[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

show more ...

[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

[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

show more ...

Fix the use of sys::MemoryFence after including WindowsSupport.h that
r271558 introduced.

llvm-svn: 271563

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 a

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

show more ...

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

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

show more ...

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 dis

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

show more ...

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 deb

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

show more ...

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_onc

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

show more ...

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.

ll

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

show more ...

Revert r211287, "Remove support for LLVM runtime multi-threading."

libclang still requires it on cygming, lack of incomplete <mutex>.

llvm-svn: 211592

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

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

show more ...