1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-23 13:02:52 +02:00
llvm-mirror/include/llvm/Support/Threading.h

120 lines
3.8 KiB
C
Raw Normal View History

//===-- llvm/Support/Threading.h - Control multithreading mode --*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file declares helper functions for running LLVM in a multi-threaded
// environment.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_SUPPORT_THREADING_H
#define LLVM_SUPPORT_THREADING_H
#include "llvm/Config/llvm-config.h" // for LLVM_ON_UNIX
[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 21:57:55 +02:00
#include "llvm/Support/Compiler.h"
#include <ciso646> // So we can check the C++ standard lib macros.
[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 21:57:55 +02:00
#include <functional>
// We use std::call_once on all Unix platforms except for NetBSD with
// libstdc++. That platform has a bug they are working to fix, and they'll
// remove the NetBSD checks once fixed.
#if defined(LLVM_ON_UNIX) && !(defined(__NetBSD__) && !defined(_LIBCPP_VERSION))
#define LLVM_THREADING_USE_STD_CALL_ONCE 1
#else
#define LLVM_THREADING_USE_STD_CALL_ONCE 0
#endif
#if LLVM_THREADING_USE_STD_CALL_ONCE
#include <mutex>
#else
#include "llvm/Support/Atomic.h"
#endif
namespace llvm {
/// Returns true if LLVM is compiled with support for multi-threading, and
/// false otherwise.
bool llvm_is_multithreaded();
/// llvm_execute_on_thread - Execute the given \p UserFn on a separate
2015-08-10 06:22:09 +02:00
/// thread, passing it the provided \p UserData and waits for thread
/// completion.
///
/// This function does not guarantee that the code will actually be executed
/// on a separate thread or honoring the requested stack size, but tries to do
/// so where system support is available.
///
/// \param UserFn - The callback to execute.
/// \param UserData - An argument to pass to the callback function.
/// \param RequestedStackSize - If non-zero, a requested size (in bytes) for
/// the thread stack.
void llvm_execute_on_thread(void (*UserFn)(void*), void *UserData,
unsigned RequestedStackSize = 0);
#if LLVM_THREADING_USE_STD_CALL_ONCE
typedef std::once_flag once_flag;
/// This macro is the only way you should define your once flag for LLVM's
/// call_once.
#define LLVM_DEFINE_ONCE_FLAG(flag) static once_flag flag
#else
enum InitStatus { Uninitialized = 0, Wait = 1, Done = 2 };
typedef volatile sys::cas_flag once_flag;
/// This macro is the only way you should define your once flag for LLVM's
/// call_once.
#define LLVM_DEFINE_ONCE_FLAG(flag) static once_flag flag = Uninitialized
#endif
/// \brief Execute the function specified as a parameter once.
///
/// Typical usage:
/// \code
/// void foo() {...};
/// ...
/// LLVM_DEFINE_ONCE_FLAG(flag);
/// call_once(flag, foo);
/// \endcode
///
/// \param flag Flag used for tracking whether or not this has run.
/// \param UserFn Function to call once.
[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 21:57:55 +02:00
template <typename Function, typename... Args>
void call_once(once_flag &flag, Function &&F, Args &&... ArgList) {
#if LLVM_THREADING_USE_STD_CALL_ONCE
std::call_once(flag, std::forward<Function>(F),
std::forward<Args>(ArgList)...);
#else
// For other platforms we use a generic (if brittle) version based on our
// atomics.
sys::cas_flag old_val = sys::CompareAndSwap(&flag, Wait, Uninitialized);
if (old_val == Uninitialized) {
std::forward<Function>(F)(std::forward<Args>(ArgList)...);
sys::MemoryFence();
TsanIgnoreWritesBegin();
TsanHappensBefore(&flag);
flag = Done;
TsanIgnoreWritesEnd();
} else {
// Wait until any thread doing the call has finished.
sys::cas_flag tmp = flag;
sys::MemoryFence();
while (tmp != Done) {
tmp = flag;
sys::MemoryFence();
}
}
TsanHappensAfter(&flag);
#endif
}
}
#endif