[all-commits] [llvm/llvm-project] 680845: [ORC] Move MaterializationResponsibility methods t...
lhames via All-commits
all-commits at lists.llvm.org
Mon Oct 19 02:00:32 PDT 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 680845ec0d6182c0dd3ac579daa37c1224d657e7
https://github.com/llvm/llvm-project/commit/680845ec0d6182c0dd3ac579daa37c1224d657e7
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm/ExecutionEngine/Orc/Core.h
M llvm/lib/ExecutionEngine/Orc/Core.cpp
Log Message:
-----------
[ORC] Move MaterializationResponsibility methods to ExecutionSession.
MaterializationResponsibility, JITDylib, and ExecutionSession collectively
manage the OrcV2 core JIT state. Responsibility for maintaining and
updating this state has previously been spread among these classes, resulting
in implementations that are each non-trivial, but all tightly coupled. This has
in turn made reading the code and reasoning about state update and locking
rules difficult.
The core state model can be simplified by thinking of
MaterializationResponsibility and JITDylib as facets of ExecutionSession. This
commit is the first in a series intended to refactor Core.cpp to reflect this
model. Operations on MaterializationResponsibility and JITDylib will forward to
implementation methods inside ExecutionSession. Raw state will remain with the
original classes, but in most cases will only be modified by the
ExecutionSession.
Commit: 5d2e359ce62f583d66d86daa7e9edfa82397a445
https://github.com/llvm/llvm-project/commit/5d2e359ce62f583d66d86daa7e9edfa82397a445
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm/ExecutionEngine/Orc/Core.h
M llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h
M llvm/include/llvm/ExecutionEngine/Orc/TPCDynamicLibrarySearchGenerator.h
M llvm/lib/ExecutionEngine/Orc/Core.cpp
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
M llvm/tools/llvm-jitlink/llvm-jitlink.cpp
M llvm/unittests/ExecutionEngine/Orc/CoreAPIsTest.cpp
Log Message:
-----------
[ORC] Move DefinitionGenerator out of JITDylib.
This will make it easier to implement asynchronous definition generators.
Commit: 069919c9ba33666786b80e89f30215ef2918ecdc
https://github.com/llvm/llvm-project/commit/069919c9ba33666786b80e89f30215ef2918ecdc
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm/ExecutionEngine/Orc/Core.h
M llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h
M llvm/include/llvm/ExecutionEngine/Orc/TPCDynamicLibrarySearchGenerator.h
M llvm/lib/ExecutionEngine/Orc/Core.cpp
M llvm/lib/ExecutionEngine/Orc/ExecutionUtils.cpp
M llvm/lib/ExecutionEngine/Orc/TPCDynamicLibrarySearchGenerator.cpp
M llvm/tools/llvm-jitlink/llvm-jitlink.cpp
M llvm/unittests/ExecutionEngine/Orc/CoreAPIsTest.cpp
M llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp
Log Message:
-----------
[ORC] Update Symbol Lookup / DefinitionGenerator system.
This patch moves definition generation out from the session lock, instead
running it under a per-dylib generator lock. It also makes the
DefinitionGenerator::tryToGenerate method optionally asynchronous: Generators
are handed an opaque LookupState object which can be captured to stop/restart
the lookup process.
The new scheme provides the following benefits and guarantees:
(1) Queries that do not need to attempt definition generation (because all
requested symbols matched against existing definitions in the JITDylib)
can proceed without being blocked by any running definition generators.
(2) Definition generators can capture the LookupState to continue their work
asynchronously. This allows generators to run for an arbitrary amount of
time without blocking a thread. Definition generators that do not need to
run asynchronously can return without capturing the LookupState to eliminate
unnecessary recursion and improve lookup performance.
(3) Definition generators still do not need to worry about concurrency or
re-entrance: Since they are still run under a (per-dylib) lock, generators
will never be re-entered concurrently, or given overlapping symbol sets to
generate.
Finally, the new system distinguishes between symbols that are candidates for
generation (generation candidates) and symbols that failed to match for a query
(due to symbol visibility). This fixes a bug where an unresolved symbol could
trigger generation of a duplicate definition for an existing hidden symbol.
Commit: c88d9eae8a71844b71ca529fd7b35d6025a84f55
https://github.com/llvm/llvm-project/commit/c88d9eae8a71844b71ca529fd7b35d6025a84f55
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Fix a memory leak in the OrcV2 C API (and some comment typos).
The LLVMOrcLLJITAddLLVMIRModule function was leaking its
LLVMOrcThreadSafeModuleRef argument. Wrapping the argument in a unique_ptr
fixes this.
Commit: 14cb9b4e21de63f74439259bad8caa6fcb7136e1
https://github.com/llvm/llvm-project/commit/14cb9b4e21de63f74439259bad8caa6fcb7136e1
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add a C API function to set the ExecutionSession error reporter.
Commit: 35e48d7b91735136e423f71c1d7406eb07a03e89
https://github.com/llvm/llvm-project/commit/35e48d7b91735136e423f71c1d7406eb07a03e89
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add C API functions to obtain and clear the symbol string pool.
Symbol string pool entries are ref counted, but not automatically cleared.
This can cause the size of the pool to grow without bound if it's not
periodically cleared. These functions allow that to be done via the C API.
Commit: 40f3fb52f706388d671124786f76143538126280
https://github.com/llvm/llvm-project/commit/40f3fb52f706388d671124786f76143538126280
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Fix C API function name.
Patch by Andres Freund. Thanks Andres!
Commit: 49c065ae70ecde9c2176da4ff801076b9c2f132b
https://github.com/llvm/llvm-project/commit/49c065ae70ecde9c2176da4ff801076b9c2f132b
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Rename LLVMOrcJITDylibDefinitionGeneratorRef.
The DefinitionGenerator class has been moved out of JITDylib. This updates
the C API type and function names to reflect that.
Commit: 91d1f417fd89cdbea095f820729df0eb9d465f9f
https://github.com/llvm/llvm-project/commit/91d1f417fd89cdbea095f820729df0eb9d465f9f
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/examples/OrcV2Examples/LLJITWithInitializers/LLJITWithInitializers.cpp
M llvm/include/llvm-c/Orc.h
M llvm/include/llvm/ExecutionEngine/Orc/LLJIT.h
M llvm/lib/ExecutionEngine/Orc/LLJIT.cpp
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add basic ResourceTracker support to the OrcV2 C Bindings.
Based on a patch by Andres Freund. Thanks Andres!
Commit: 4b477e776382a083e2bee2c1eb66068ad9186189
https://github.com/llvm/llvm-project/commit/4b477e776382a083e2bee2c1eb66068ad9186189
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/examples/OrcV2Examples/CMakeLists.txt
A llvm/examples/OrcV2Examples/OrcV2CBindingsRemovableCode/CMakeLists.txt
A llvm/examples/OrcV2Examples/OrcV2CBindingsRemovableCode/OrcV2CBindingsRemovableCode.c
Log Message:
-----------
[ORC] Add an OrcV2 ResourceTracker / Removable-code example.
Commit: 19402ce79a896563823fff45b853f229df4c1261
https://github.com/llvm/llvm-project/commit/19402ce79a896563823fff45b853f229df4c1261
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Error.h
M llvm/lib/Support/Error.cpp
Log Message:
-----------
[Support] Add a C-API function to create a StringError instance.
This will allow C API clients to return errors from callbacks. This
functionality will be used in upcoming Orc C-bindings functions.
Commit: b6ca0c7dd53528cece4e058eb12c281792893b2f
https://github.com/llvm/llvm-project/commit/b6ca0c7dd53528cece4e058eb12c281792893b2f
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/include/llvm/ExecutionEngine/Orc/Core.h
M llvm/lib/ExecutionEngine/Orc/Core.cpp
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add support for custom generators to the C bindings.
C API clients can now define a custom definition generator by providing a
callback function (to implement DefinitionGenerator::tryToGenerate) and context
object. All arguments for the DefinitionGenerator::tryToGenerate method have
been given C API counterparts, and the API allows for optionally asynchronous
generation.
Commit: 24afffe63a7b0c545ab854f7955c9b4322e7e690
https://github.com/llvm/llvm-project/commit/24afffe63a7b0c545ab854f7955c9b4322e7e690
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add C API support for defining absolute symbols.
Also tweaks the definition of TryToGenerate to make it dovetail more neatly
with the new function.
Commit: 00369849e10943b3afd35505504368a8cdc77100
https://github.com/llvm/llvm-project/commit/00369849e10943b3afd35505504368a8cdc77100
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/include/llvm-c/Orc.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Add function to get pool entry string.
Patch by Andres Freund. Thanks Andres!
Commit: f35707047e216e99052c15b04fe508d075b6121b
https://github.com/llvm/llvm-project/commit/f35707047e216e99052c15b04fe508d075b6121b
Author: Lang Hames <lhames at gmail.com>
Date: 2020-10-19 (Mon, 19 Oct 2020)
Changed paths:
M llvm/examples/OrcV2Examples/OrcV2CBindingsAddObjectFile/OrcV2CBindingsAddObjectFile.c
M llvm/examples/OrcV2Examples/OrcV2CBindingsBasicUsage/OrcV2CBindingsBasicUsage.c
M llvm/examples/OrcV2Examples/OrcV2CBindingsReflectProcessSymbols/OrcV2CBindingsReflectProcessSymbols.c
M llvm/examples/OrcV2Examples/OrcV2CBindingsRemovableCode/OrcV2CBindingsRemovableCode.c
A llvm/include/llvm-c/LLJIT.h
M llvm/include/llvm-c/Orc.h
A llvm/include/llvm-c/OrcEE.h
M llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp
Log Message:
-----------
[ORC] Break up C-API header Orc.h, and add JITEventListener support.
This patch breaks Orc.h up into Orc.h, LLJIT.h and OrcEE.h.
Orc.h contain core Orc utilities.
LLJIT.h contains LLJIT specific types and functions.
OrcEE.h contains types and functions that depend on ExecutionEngine.
The intent is that these headers should match future library divisions: Clients
who only use Orc.h should only need to link againt the Orc core libraries,
clients using LLJIT.h will also need to link against LLVM core, and clients
using OrcEE.h will also have to link against ExecutionEngine.
In addition to breaking up the Orc.h header this patch introduces functions to:
(1) Set the object linking layer creation function on LLJITBuilder.
(2) Create an RTDyldObjectLinkingLayer instance (particularly for use in (1)).
(3) Register JITEventListeners with an RTDyldObjectLinkingLayer.
Together (1), (2) and (3) can be used to force use of RTDyldObjectLinkingLayer
as the underlying JIT linker for LLJIT, rather than the platform default, and
to register event listeners with the RTDyldObjectLinkingLayer.
Compare: https://github.com/llvm/llvm-project/compare/8a7ca143f8bd...f35707047e21
More information about the All-commits
mailing list