[ORC] Rename ThreadSafeModule::takingModuleDo to consumingModuleDo.

Renamed to emphasize intent: this method allows the module to be consumed by the
callback (while protected by the context lock), b

[ORC] Rename ThreadSafeModule::takingModuleDo to consumingModuleDo.

Renamed to emphasize intent: this method allows the module to be consumed by the
callback (while protected by the context lock), but we don't want to imply that
the Module could be taken out of the ThreadSafeModule (where it would no longer
be protected by that lock).

show more ...

[ORC] Add ThreadSafeModule::takingModuleDo for consuming operations on TSMs.

ThreadSafeModule::takingModuleDo passes ownership of the contained llvm::Module
into the callback, allowing ThreadSafeMod

[ORC] Add ThreadSafeModule::takingModuleDo for consuming operations on TSMs.

ThreadSafeModule::takingModuleDo passes ownership of the contained llvm::Module
into the callback, allowing ThreadSafeModules to be used with consuming
operations like Linker::link.

show more ...

[llvm] LLVM_NODISCARD => [[nodiscard]]. NFC

With C++17 there is no Clang pedantic warning.

[llvm] Fix header guards (NFC)

Identified with llvm-header-guard.

[ORC] cloneToNewContext() can work with a const-ref to ThreadSafeModule

Use C++14-style return type deduction in LLVM.

Summary:
Simplifies the C++11-style "-> decltype(...)" return-type deduction.

Note that you have to be careful about whether the function return type

Use C++14-style return type deduction in LLVM.

Summary:
Simplifies the C++11-style "-> decltype(...)" return-type deduction.

Note that you have to be careful about whether the function return type
is `auto` or `decltype(auto)`. The difference is that bare `auto`
strips const and reference, just like lambda return type deduction. In
some cases that's what we want (or more likely, we know that the return
type is a value type), but whenever we're wrapping a templated function
which might return a reference, we need to be sure that the return type
is decltype(auto).

No functional change.

Subscribers: dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74383

show more ...

[ORC] Remove a layer of indirection when locking the mutex. NFCI.

llvm-svn: 367781

[ORC] Change the locking scheme for ThreadSafeModule.

ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking
for LLVMContexts in ORCv2. Prior to this patch contexts were locked

[ORC] Change the locking scheme for ThreadSafeModule.

ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking
for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon
as an associated Module was emitted (to be compiled and linked), and were not
unlocked until the emit call returned. This could lead to deadlocks if
interdependent modules that shared contexts were compiled on different threads:
when, during emission of the first module, the dependence was discovered the
second module (which would provide the required symbol) could not be emitted as
the thread emitting the first module still held the lock.

This patch eliminates this possibility by moving to a finer-grained locking
scheme. Each client holds the module lock only while they are actively operating
on it. To make this finer grained locking simpler/safer to implement this patch
removes the explicit lock method, 'getContextLock', from ThreadSafeModule and
replaces it with a new method, 'withModuleDo', that implicitly locks the context,
calls a user-supplied function object to operate on the Module, then implicitly
unlocks the context before returning the result.

ThreadSafeModule TSM = getModule(...);
size_t NumFunctions = TSM.withModuleDo(
[](Module &M) { // <- context locked before entry to lambda.
return M.size();
});

Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the
new method.

This method is used to introduce Module locking into each of the existing
layers.

llvm-svn: 367686

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

[ORC] Add more utilities to aid debugging output.

(1) A const accessor for the LLVMContext held by a ThreadSafeContext.

(2) A const accessor for the ThreadSafeModules held by an IRMaterializationUn

[ORC] Add more utilities to aid debugging output.

(1) A const accessor for the LLVMContext held by a ThreadSafeContext.

(2) A const accessor for the ThreadSafeModules held by an IRMaterializationUnit.

(3) A const MaterializationResponsibility reference to IRTransformLayer2's
transform function. This makes IRTransformLayer2 useful for JIT debugging
(since it can inspect JIT state through the responsibility argument) as well
as program transformations.

llvm-svn: 343365

show more ...

[ORC] clang-format the ThreadSafeModule code.

Evidently I forgot to do this before committing r343055.

llvm-svn: 343288

[ORC] Add a const version of ThreadSafeModule::getModule().

llvm-svn: 343287

[ORC] Lock ThreadSafeContext during module destruction in ThreadSafeModule's
move constructor.

This is basically the same fix as r343261, but applied to the move constructor:
Failure to lock the con

[ORC] Lock ThreadSafeContext during module destruction in ThreadSafeModule's
move constructor.

This is basically the same fix as r343261, but applied to the move constructor:
Failure to lock the context during module destruction can lead to data races if
other threads are operating on the context.

llvm-svn: 343286

show more ...

[ORC] Lock ThreadSafeContext during Module destructing in ThreadSafeModule.

Failure to lock the context can lead to data races if other threads are
operating on other ThreadSafeModules that share th

[ORC] Lock ThreadSafeContext during Module destructing in ThreadSafeModule.

Failure to lock the context can lead to data races if other threads are
operating on other ThreadSafeModules that share the same context.

llvm-svn: 343261

show more ...

Revert "Re-revert r343129."

This reverts commit 4e2557dbc76704beb8c4cf1191cb786e719db5d3.

llvm-svn: 343161

Re-revert r343129.

Apparently the fixes in r343149 did not cover all the issues. Re-reverting
while I investigate.

llvm-svn: 343151

Reapply r343129 with fix.

Explicitly defines ThreadSafeModule's move-assignment operator to move fields in
reverse order. This is required to ensure that the context field outlives the
module field.

Reapply r343129 with fix.

Explicitly defines ThreadSafeModule's move-assignment operator to move fields in
reverse order. This is required to ensure that the context field outlives the
module field.

llvm-svn: 343149

show more ...

Revert r343129 "[ORC] Change the field order of ThreadSafeModule to ensure the "

It broke several bots.

llvm-svn: 343133

[ORC] Change the field order of ThreadSafeModule to ensure the Module is
destroyed before its ThreadSharedContext.

Destroying the context first is an error if this ThreadSafeModule is the only
owner

[ORC] Change the field order of ThreadSafeModule to ensure the Module is
destroyed before its ThreadSharedContext.

Destroying the context first is an error if this ThreadSafeModule is the only
owner of its underlying context.

Add a unit test for ThreadSafeModule/ThreadSafeContext to catch this and other
basic usage issues.

llvm-svn: 343129

show more ...

[ORC] Include-what-you-use fixes.

llvm-svn: 343057

[ORC] Fix a missing include in r343055.

llvm-svn: 343056

[ORC] Add ThreadSafeModule and ThreadSafeContext wrappers to support concurrent
compilation of IR in the JIT.

ThreadSafeContext is a pair of an LLVMContext and a mutex that can be used to
lock that

[ORC] Add ThreadSafeModule and ThreadSafeContext wrappers to support concurrent
compilation of IR in the JIT.

ThreadSafeContext is a pair of an LLVMContext and a mutex that can be used to
lock that context when it needs to be accessed from multiple threads.

ThreadSafeModule is a pair of a unique_ptr<Module> and a
shared_ptr<ThreadSafeContext>. This allows the lifetime of a ThreadSafeContext
to be managed automatically in terms of the ThreadSafeModules that refer to it:
Once all modules using a ThreadSafeContext are destructed, and providing the
client has not held on to a copy of shared context pointer, the context will be
automatically destructed.

This scheme is necessary due to the following constraits: (1) We need multiple
contexts for multithreaded compilation (at least one per compile thread plus
one to store any IR not currently being compiled, though one context per module
is simpler). (2) We need to free contexts that are no longer being used so that
the JIT does not leak memory over time. (3) Module lifetimes are not
predictable (modules are compiled as needed depending on the flow of JIT'd
code) so there is no single point where contexts could be reclaimed.

JIT clients not using concurrency can safely use one ThreadSafeContext for all
ThreadSafeModules.

JIT clients who want to be able to compile concurrently should use a different
ThreadSafeContext for each module, or call setCloneToNewContextOnEmit on their
top-level IRLayer. The former reduces compile latency (since no clone step is
needed) at the cost of additional memory overhead for uncompiled modules (as
every uncompiled module will duplicate the LLVM types, constants and metadata
that have been shared).

llvm-svn: 343055

show more ...