Swift stable jit updates #2017
Merged
Swift stable jit updates #2017
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The example demonstrates how to use a module summary index file produced for ThinLTO to: * find the module that defines the main entry point * find all extra modules that are required for the build A LIT test runs the example as part of the LLVM test suite [1] and shows how to create a module summary index file. The code also provides two Error types that can be useful when working with ThinLTO summaries. [1] if LLVM_BUILD_EXAMPLES=ON and platform is not Windows Differential Revision: https://reviews.llvm.org/D85974
This will make stateful registrars (e.g. a future TargetProcessControl based registrar) easier to deal with.
DFS and Reverse-DFS linkage orders are used to order execution of deinitializers and initializers respectively. This patch replaces uses of special purpose DFS order functions in MachOPlatform and LLJIT with uses of the new methods.
The unused Main variable was accidentally left in an earlier commit.
A think-o in the existing code meant that dependencies were never registered. This failure could lead to crashes rather than orderly error propagation if initialization dependencies failed to materialize. No test case: The bug was discovered in an out-of-tree code and requires pathalogically misconfigured JIT to generate the original error that lead to the crash.
If there's no initializer symbol in the current MaterializationResponsibility then bail out without installing JITLink passes: they're going to be no-ops anyway.
…jitlink. TPCDynamicLibrarySearchGenerator was generating errors on missing symbols, but that doesn't fit the DefinitionGenerator contract: A symbol that isn't generated by a particular generator should not cause an error. This commit fixes the error by using SymbolLookupFlags::WeaklyReferencedSymbol for all elements of the lookup, and switches llvm-jitlink to use TPCDynamicLibrarySearchGenerator.
Making MaterializationResponsibility instances immovable allows their associated VModuleKeys to be updated by the ExecutionSession while the responsibility is still in-flight. This will be used in the upcoming removable code feature to enable safe merging of resource keys even if there are active compiles using the keys being merged.
…nique_ptr." This reverts commit c74900c. This appears to be breaking some builds on macOS and has been causing build failures on Green Dragon (see below). I am reverting this for now, to unblock testing on Green Dragon. http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/18144/console [65/187] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBUILD_EXAMPLES -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iexamples/ThinLtoJIT -I/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT -Iinclude -I/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.9 -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -MT examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o -MF examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o.d -o examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o -c /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp FAILED: examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBUILD_EXAMPLES -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iexamples/ThinLtoJIT -I/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT -Iinclude -I/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -O3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -mmacosx-version-min=10.9 -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -MT examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o -MF examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o.d -o examples/ThinLtoJIT/CMakeFiles/ThinLtoJIT.dir/ThinLtoDiscoveryThread.cpp.o -c /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp In file included from /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT/ThinLtoDiscoveryThread.cpp:7: /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/examples/ThinLtoJIT/ThinLtoInstrumentationLayer.h:37:68: error: non-virtual member function marked 'override' hides virtual member function void emit(MaterializationResponsibility R, ThreadSafeModule TSM) override; ^ /Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Layer.h:103:16: note: hidden overloaded virtual function 'llvm::orc::IRLayer::emit' declared here: type mismatch at 1st parameter ('std::unique_ptr<MaterializationResponsibility>' vs 'llvm::orc::MaterializationResponsibility') virtual void emit(std::unique_ptr<MaterializationResponsibility> R, ^ 1 error generated.
… fixes. Re-applies c74900c with fixes for the ThinLtoJIT example.
All of these forward declarations are fully defined in headers that are directly included.
…ormLayer. Shows how to write a custom IR transform to apply a legacy::PassManager pipeline.
…C lands This solves a phase ordering problem: OrcV2 remote process support depends on OrcV2 removable code, OrcV2 removable code depends on OrcV1 removal, OrcV1 removal depends on LLJITWithChildProcess migration, and LLJITWithChildProcess migration depends on OrcV2 TargetProcessControl support.
This patch enables basic BSS section handling, and improves a couple of error messages in the ELF section parsing code. Patch by Christian Schafmeister. Thanks Christian! Differential Revision: https://reviews.llvm.org/D88867
…diagnostic. Report a fatal error if an IMAGE_REL_AMD64_ADDR32NB cannot be applied due to an out-of-range target. Previously we emitted a diagnostic to llvm::errs and continued. Patch by Dale Martin. Thanks Dale!
This removes all legacy layers, legacy utilities, the old Orc C bindings, OrcMCJITReplacement, and OrcMCJITReplacement regression tests. ExecutionEngine and MCJIT are not affected by this change.
This patch introduces new APIs to support resource tracking and removal in Orc. It is intended as a thread-safe generalization of the removeModule concept from OrcV1. Clients can now create ResourceTracker objects (using JITDylib::createResourceTracker) to track resources for each MaterializationUnit (code, data, aliases, absolute symbols, etc.) added to the JIT. Every MaterializationUnit will be associated with a ResourceTracker, and ResourceTrackers can be re-used for multiple MaterializationUnits. Each JITDylib has a default ResourceTracker that will be used for MaterializationUnits added to that JITDylib if no ResourceTracker is explicitly specified. Two operations can be performed on ResourceTrackers: transferTo and remove. The transferTo operation transfers tracking of the resources to a different ResourceTracker object, allowing ResourceTrackers to be merged to reduce administrative overhead (the source tracker is invalidated in the process). The remove operation removes all resources associated with a ResourceTracker, including any symbols defined by MaterializationUnits associated with the tracker, and also invalidates the tracker. These operations are thread safe, and should work regardless of the the state of the MaterializationUnits. In the case of resource transfer any existing resources associated with the source tracker will be transferred to the destination tracker, and all future resources for those units will be automatically associated with the destination tracker. In the case of resource removal all already-allocated resources will be deallocated, any if any program representations associated with the tracker have not been compiled yet they will be destroyed. If any program representations are currently being compiled then they will be prevented from completing: their MaterializationResponsibility will return errors on any attempt to update the JIT state. Clients (usually Layer writers) wishing to track resources can implement the ResourceManager API to receive notifications when ResourceTrackers are transferred or removed. The MaterializationResponsibility::withResourceKeyDo method can be used to create associations between the key for a ResourceTracker and an allocated resource in a thread-safe way. RTDyldObjectLinkingLayer and ObjectLinkingLayer are updated to use the ResourceManager API to enable tracking and removal of memory allocated by the JIT linker. The new JITDylib::clear method can be used to trigger removal of every ResourceTracker associated with the JITDylib (note that this will only remove resources for the JITDylib, it does not run static destructors). This patch includes unit tests showing basic usage. A follow-up patch will update the Kaleidoscope and BuildingAJIT tutorial series to OrcV2 and will use this API to release code associated with anonymous expressions.
…to OrcV2. This patch updates the Kaleidoscope and BuildingAJIT tutorial series (chapter 1-4) to OrcV2. Chapter 5 of the BuildingAJIT series is removed -- it will be re-instated once we have in-tree support for out-of-process JITing. This patch only updates the tutorial code, not the text. Patches welcome for that, otherwise I will try to update it in a few weeks.
…ctor. MSVC doesn't seem to like capturing references to variables in lambdas passed to the variable's constructor. This should fix the windows bots that have been unable to build the new ResourceTracker unit test.
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.
This will make it easier to implement asynchronous definition generators.
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.
The LLVMOrcLLJITAddLLVMIRModule function was leaking its LLVMOrcThreadSafeModuleRef argument. Wrapping the argument in a unique_ptr fixes this.
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.
Patch by Andres Freund. Thanks Andres!
The DefinitionGenerator class has been moved out of JITDylib. This updates the C API type and function names to reflect that.
Based on a patch by Andres Freund. Thanks Andres!
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.
Also tweaks the definition of TryToGenerate to make it dovetail more neatly with the new function.
Patch by Andres Freund. Thanks Andres!
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.
Thanks for spotting this Mehdi!
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick recent LLVM mainline JIT changes.