Commit Graph

629 Commits

Author SHA1 Message Date
Lang Hames 121302ac62 [ORC] Add explicit cast to fix a narrowing conversion error. 2020-07-16 15:33:02 -07:00
Lang Hames 0e940d55f8 [ORC] Add TargetProcessControl and TPCIndirectionUtils APIs.
TargetProcessControl is a new API for communicating with JIT target processes.
It supports memory allocation and access, and inspection of some process
properties, e.g. the target proces triple and page size.

Centralizing these APIs allows utilities written against TargetProcessControl
to remain independent of the communication procotol with the target process
(which may be direct memory access/allocation for in-process JITing, or may
involve some form of IPC or RPC).

An initial set of TargetProcessControl-based utilities for lazy compilation is
provided by the TPCIndirectionUtils class.

An initial implementation of TargetProcessControl for in-process JITing
is provided by the SelfTargetProcessControl class.

An example program showing how the APIs can be used is provided in
llvm/examples/OrcV2Examples/LLJITWithTargetProcessControl.
2020-07-16 15:09:13 -07:00
Abhina Sreeskantharajan eed19bd844 [NFC] [AIX] [z/OS] Fix build failure on AIX and z/OS
Summary: This PR contains a build failure fix that occurs on both AIX and z/OS as a result of this commit https://reviews.llvm.org/rG670915094462d831e3733e5b01a76471b8cf6dd8.

Reviewers: uweigand, Kai, hubert.reinterpretcast, daltenty, lhames

Reviewed By: Kai, hubert.reinterpretcast, daltenty

Subscribers: SeanP, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83889
2020-07-15 16:07:34 -04:00
Richard Smith 71292379d7 Make LazyCallThroughManager destructor virtual rather than arranging for
all clients to delete it via the correct dynamic type.
2020-07-14 18:41:07 -07:00
Richard Smith 099fd37484 Fix undefined behavior due to deleting an object with a non-virtual
destructor via a pointer of the wrong static type.

This caused crashes during deallocation in C++14 builds when using a
deallocator whose sized delete requires the size argument to be correct.

Also make the LazyCallThroughManager destructor protected to catch this
sort of bug in the future.
2020-07-14 17:17:20 -07:00
Lang Hames 3d931e85f1 [ORC] Don't take ownership of the trampoline pool in LazyReexportsManager.
LazyReexportsManager instances use the trampoline pool, but they don't need to
own it. Keeping TrampolinePool ownership separate allows re-use of the
trampoline pool by other clients.
2020-07-14 10:56:45 -07:00
Lang Hames 31b5b12129 [ORC] Remove a spurious reinterpret_cast. 2020-07-13 12:39:24 -07:00
Lang Hames fb7ef0bb0b [ORC] Generalize emit re-entry, stub, etc. APIs for working addr != link addr.
This patch generalizes the APIs for writing re-entry blocks, trampolines and
stubs to allow their final linked address to differ from the address of
their initial working memory. This will allow these routines to be used with
JITLinkMemoryManagers, which will in turn allow for unification of code paths
for in-process and cross-process lazy JITing.
2020-07-13 10:15:10 -07:00
Lang Hames 6709150944 [ORC] Modify LazyCallThroughManager to support asynchronous resolution.
Asynchronous resolution is a better fit for handling reentry over
IPC/RPC where we want to avoid blocking a communication handler/thread.
2020-07-08 21:13:55 -07:00
Lang Hames e429cffd4f [ORC] Always use ObjectLinkingLayer/JITLink for MachO on x86-64 and arm64.
JITLink supports all code and relocation models, so there's no reason to
conditionalize using JITLink on the code or relocation model settings.

Clients wanting to use RTDyldObjectLinkingLayer/RuntimeDyld will now
need to use a custom object linking layer creator.
2020-06-05 21:02:29 -07:00
Lang Hames ff92d3c672 [ORC] Add debugging output for LLJIT construction.
This can be handy for checking whether the LLJIT instance you're constructing
matches your expectations.
2020-05-28 20:31:50 -07:00
Lang Hames 41379f1ec4 [ORC] Share ownership of JITDylibs between ExecutionSession and
MaterializationResponsibility.

MaterializationResponsibility objects provide a connection between a
materialization process (compiler, jit linker, etc.) and the JIT state held in
the ExecutionSession and JITDylib objects. Switching to shared ownership
extends the lifetime of JITDylibs to ensure they remain accessible until all
materializers targeting them have completed. This will allow (in a follow-up
patch) JITDylibs to be removed from the ExecutionSession and placed in a
pending-destruction state while they are kept alive to communicate errors
to/from any still-runnning materialization processes. The intent is to enable
JITDylibs to be safely removed even if they have running compiles targeting
them.
2020-05-10 16:37:17 -07:00
Lang Hames c66f89005f [ORC] Rename SearchOrder operations on JITDylib to LinkOrder.
Refering to the link order of a dylib better matches the terminology used in
static compilation. As upcoming patches will increase the number of places where
link order matters (for example when closing JITDylibs) it's better to get this
name change out of the way early.
2020-05-04 16:47:52 -07:00
Craig Topper 05a11974ae [CallSite removal] Remove unneeded includes of CallSite.h. NFC 2020-04-22 00:07:13 -07:00
Lang Hames c6ade39ba0 [ORC] Replace LLJIT::defineAbsolute with an LLJIT::define convenience method.
LLJIT::defineAbsolute did not mangle its Name argument, which is inconsistent
with the behavior of other LLJIT methods (e.g. lookup). Since it is currently
unused anyway, this commit replaces it with a generic 'define' convenience
method for adding MaterializationUnits to the main JITDylib. This simplifies
use of the generic absoluteSymbols function (as well as the symbolAlias,
reexports and other functions that generate MaterializationUnits) with LLJIT.
2020-04-18 14:16:54 -07:00
vgxbj ac00376a13 [Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> getSymbolFlags().
This change enables getSymbolFlags() to return errors which benefit error reporting in clients.

Differential Revision: https://reviews.llvm.org/D77860
2020-04-18 21:27:57 +08:00
Lang Hames 59ed45b483 [ORC] Add an OrcV2 C API function for configuring TargetMachines. 2020-04-10 15:51:29 -07:00
Lang Hames 37bcf2df01 [ORC] Require JITDylib to be specified when adding IR and objects in the C API. 2020-04-09 17:59:26 -07:00
Lang Hames 0d5f15f700 [ORC] Add C API support for adding object files to an LLJIT instance. 2020-04-09 16:18:46 -07:00
Lang Hames 1cd8493e69 [ORC] Expand the OrcV2 C API bindings.
Adds basic support for LLJITBuilder and DynamicLibrarySearchGenerator. This
allows C API clients to configure LLJIT to expose process symbols to JIT'd
code. An example of this is added in
llvm/examples/OrcV2CBindingsReflectProcessSymbols.
2020-04-09 16:18:46 -07:00
Lang Hames 5877d6f5f4 [ORC] Make mangling convenience methods part of the public API of LLJIT.
This saves clients from having to manually construct a MangleAndInterner.
2020-04-08 20:20:13 -07:00
Lang Hames 1b39c6f62c [ORC] Add MachO universal binary support to StaticLibraryDefinitionGenerator.
Add a new overload of StaticLibraryDefinitionGenerator::Load that takes a triple
argument and supports loading archives from MachO universal binaries in addition
to regular archives.

The LLI tool is updated to use this overload.
2020-04-05 20:21:05 -07:00
Lang Hames 05598441de Re-apply 0071eaaf08, "[ORC] Export __cxa_atexit ...", with fixes.
Forgot to include part of the testcase. Thank to Nico for spotting that and
reverting!
2020-04-02 16:03:35 -07:00
Nico Weber 5bac8d427d Revert "[ORC] Export __cxa_atexit from the main JITDylib in LLJIT."
This reverts commit 0071eaaf08.
Inputs/noop-main.ll wasn't checked in, so this breaks check-llvm
everywhere.
2020-04-01 22:49:38 -04:00
Lang Hames 0071eaaf08 [ORC] Export __cxa_atexit from the main JITDylib in LLJIT.
Failure to export __cxa_atexit can lead to an attempt to import a definition
from the process itself (if __cxa_atexit is referenced from another JITDylib),
but the process definition will clash with the existing non-exported definition
to produce an unexpected DuplicateDefinitionError.

This patch fixes the immediate issue by exporting __cxa_atexit. It also fixes a
bug where atexit functions in other JITDylibs were not being run by adding a
copy of run_atexits_helper to every JITDylib.

A follow up patch will deal with the bug where definition generators are called
despite a non-exported definition being present.
2020-04-01 19:12:08 -07:00
Lang Hames 8e5a8f620c [ORC] Don't require a null-terminator on MemoryBuffers for objects in archives.
The MemoryBuffer::getMemBuffer method's RequiresNullTerminator parameter
defaults to true, but object files are not null terminated so we need to
explicitly pass false here.
2020-04-01 12:16:38 -07:00
Lang Hames cb84e4827e [ORC] Introduce JITSymbolFlags::HasMaterializeSideEffectsOnly flag.
This flag can be used to mark a symbol as existing only for the purpose of
enabling materialization. Such a symbol can be looked up to trigger
materialization with the lookup returning only once materialization is
complete. Symbols with this flag will never resolve however (to avoid
permanently polluting the symbol table), and should only be looked up using
the SymbolLookupFlags::WeaklyReferencedSymbol flag. The primary use case for
this flag is initialization symbols.
2020-03-27 11:02:54 -07:00
Lang Hames d38d06e649 [ORC] Don't create MaterializingInfo entries unnecessarily. 2020-03-27 11:02:54 -07:00
Alina Sbirlea 3abcbf9903 [CFG/BasicBlock] Rename succ_const to const_succ. [NFC]
Summary:
Rename `succ_const_iterator` to `const_succ_iterator` and
`succ_const_range` to `const_succ_range` for consistency with the
predecessor iterators, and the corresponding iterators in
MachineBasicBlock.

Reviewers: nicholas, dblaikie, nlewycky

Subscribers: hiraditya, bmahjour, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75952
2020-03-25 12:40:55 -07:00
Lang Hames 38a8760b99 [ORC] Move ostream operators for debugging output out of Core.h.
DebugUtils.h seems like a more appropriate home for these.
2020-03-21 18:27:28 -07:00
Lang Hames 39253a50f0 [ORC] Re-apply 98f2bb4461, enable JITEventListeners in OrcV2, with fixes.
Updates the object buffer ownership scheme in jitLinkForOrc and related
functions: Ownership of both the object::ObjectFile and underlying
MemoryBuffer is passed into jitLinkForOrc and passed back to the onEmit
callback once linking is complete. This avoids the use-after-free errors
that were seen in 98f2bb4461.
2020-03-19 16:30:08 -07:00
Lang Hames 54aec178da [ORC] Don't use a platform mutex for LLJIT's GenericLLVMIRPlatformSupport class.
Along the same lines as eb918d8daf1: This code also had to acquire the session
mutex, and this could cause a deadlock under the wrong circumstances. This
patch updates GenericLLVMIRPlatformSupport to just use the session lock for
everything.
2020-03-19 11:03:34 -07:00
Lang Hames ad2da631bf [ORC] Fix indentation in debugging output. 2020-03-19 11:02:56 -07:00
Lang Hames eb918d8daf [ORC] Use finer-grained and session locking in MachOPlatform to avoid deadlock.
In MachOPlatform, obtaining the link-order for a JITDylib requires locking the
session, but also needs to be part of a larger atomic operation that collates
initializer symbols tracked by the platform. Trying to do this under a separate
platform mutex leads to potential locking order issues, e.g.

T1 locks session then tries to lock platform to register a new init symbol
meanwhile
T2 locks platform then tries to lock session to obtain link order.

Removing the platform lock and performing all these operations under the session
lock eliminates this possibility.

At the same time we also need to collate init pointers from the
MachOPlatform::InitScraperPlugin, and we don't need or want to lock the session
for that. The new InitSeqMutex has been added to guard these init pointers, and
the session mutex is never obtained while the InitSeqMutex is held.
2020-03-19 11:02:56 -07:00
Lang Hames a7b8393ffe [ORC] Don't waste time building empty replacement MaterializationUnits. 2020-03-19 11:02:56 -07:00
Lang Hames cd34c0570b [ORC] Bail out early if a replacement MaterializationUnit is empty.
The MU may define no symbols, but still contain a non-trivial destructor (e.g.
an LLVM IR module that has been stripped of all externally visible
definitions, but which still needs to lock its context to be destroyed).
Bailing out early ensures that we destroy the unit outside the session lock,
rather than under it which may cause deadlocks.

Also adds some extra sanity-checking assertions.
2020-03-19 11:02:56 -07:00
Lang Hames 9c5771710e Revert "[ORC] Enable JITEventListeners in the RTDyldObjectLinkingLayer."
This reverts commit 98f2bb4461.

Reverting while I investigate bot failures.
2020-03-15 15:35:08 -07:00
Lang Hames 98f2bb4461 [ORC] Enable JITEventListeners in the RTDyldObjectLinkingLayer.
Enable use of ExecutionEngine JITEventListeners in RTDyldObjectLinkingLayer.
This allows existing MCJIT clients to more easily migrate to LLJIT / ORCv2.

Example usage in llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener.

Differential Revision: https://reviews.llvm.org/D75838
2020-03-15 15:14:46 -07:00
Lang Hames 981f017c5c [ORC] Print symbol flags and materializer name in ExecutionSession::dump.
The extra information can be helpful in diagnosing JIT bugs.
2020-03-14 18:52:10 -07:00
Lang Hames 9c9eb60b4b [JITLink][MachO] Re-apply b64afadf30, MachO linker-private support, with fixes.
Global symbols with linker-private prefixes should be resolvable across object
boundaries, but internal symbols with linker-private prefixes should not.
2020-03-14 18:36:15 -07:00
Lang Hames a7d187d9c0 Revert "[JITLink][MachO] Treat linker private symbols as hidden rather than private."
This reverts commit b64afadf30.

Reverting while I investigate bot failures.
2020-03-14 16:52:25 -07:00
Lang Hames b64afadf30 [JITLink][MachO] Treat linker private symbols as hidden rather than private.
Linker-private symbols should be resolvable across object file boundaries.
2020-03-14 16:33:15 -07:00
Lang Hames 633ea07200 [Orc] Add basic OrcV2 C bindings and example.
Renames the llvm/examples/LLJITExamples directory to llvm/examples/OrcV2Examples
since it is becoming a home for all OrcV2 examples, not just LLJIT.

See http://llvm.org/PR31103.
2020-03-14 14:41:22 -07:00
Jan Korous b7ce8fa91e [LLJIT] Add std::move() as a workaround for older compilers
Clang 3.8 isn't able to bind the variable to rvalue-ref which breaks the build.
2020-03-13 15:25:25 -07:00
Lang Hames 7266a8bfeb [ORC] Enable exception handling in JIT'd code when using LLJIT on Darwin.
This patch enables exception handling in code added to LLJIT on Darwin by
adding an orc::EHFrameRegistrationPlugin instance to the ObjectLinkingLayer
(which is currently used on Darwin only).
2020-03-12 15:33:56 -07:00
Lang Hames 214a9f0dd4 [ORC] Add a mutex to guard EHFrameRegistrationPlugin data structures.
These may be accessed from multiple threads if concurrent materialization is
enabled in ORC.

Testcase coming in a follow-up patch that enables eh-frame registration for
LLJIT.
2020-03-12 15:33:56 -07:00
Lang Hames b19801640b [ORC] Fix an overly aggressive assert.
It is ok to add dependencies on symbols that are ready, they should just be
skipped.
2020-03-11 20:04:54 -07:00
Lang Hames 4b87f9230b [ORC] Add some extra debugging output. 2020-03-11 20:04:54 -07:00
Lang Hames 4b15decb60 [ORC] Remove hard dependency on libobjc when using MachOPlatform with LLJIT.
The LLJIT::MachOPlatformSupport class used to unconditionally attempt to
register __objc_selrefs and __objc_classlist sections. If libobjc had not
been loaded this resulted in an assertion, even if no objc sections were
actually present. This patch replaces this unconditional registration with
a check that no objce sections are present if libobjc has not been loaded.
This will allow clients to use MachOPlatform with LLJIT without requiring
libobjc for non-objc code.
2020-03-04 21:49:28 -08:00
Stefan Gränitz 76c59a63bc [ORC] Decompose LazyCallThroughManager::callThroughToSymbol()
Summary: Decompose callThroughToSymbol() into findReexport(), resolveSymbol(), notifyResolved() and reportCallThroughError(). This allows derived classes to reuse the functionality while adding their own code in between.

Reviewers: lhames

Reviewed By: lhames

Subscribers: hiraditya, steven_wu, dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75084
2020-03-05 00:24:23 +01:00
Lang Hames 8363ff04af [ORC] Add some debugging output for initializers.
This output can be useful in tracking down initialization failures in the JIT.
2020-03-04 12:38:25 -08:00
Lang Hames 31e0331763 [ORC] Skip ST_File symbols in MaterializationUnit interfaces / resolution.
ST_File symbols aren't relevant for linking purposes, but can end up shadowing
real symbols if they're not filtered.

No test case yet: The ideal testcase for this would be an ELF llvm-jitlink test,
but llvm-jitlink support for ELF is still under development. We should add a
testcase for this once support lands in tree.
2020-03-03 16:15:44 -08:00
Lang Hames ff4fd8dead [ORC] Make sure we add initializers to the SymbolFlags map for objects. 2020-03-03 09:33:37 -08:00
Lang Hames 22ed8c4994 [ORC] Remove an out-of-date FIXME 2020-03-03 09:33:37 -08:00
Reid Kleckner af450eabb9 Avoid including FileSystem.h from MemoryBuffer.h
Lots of headers pass around MemoryBuffer objects, but very few open
them. Let those that do include FileSystem.h.

Saves ~250 includes of Chrono.h & FileSystem.h:

$ diff -u thedeps-before.txt thedeps-after.txt | grep '^[-+] ' | sort | uniq -c | sort -nr
    254 -    ../llvm/include/llvm/Support/FileSystem.h
    253 -    ../llvm/include/llvm/Support/Chrono.h
    237 -    ../llvm/include/llvm/Support/NativeFormatting.h
    237 -    ../llvm/include/llvm/Support/FormatProviders.h
    192 -    ../llvm/include/llvm/ADT/StringSwitch.h
    190 -    ../llvm/include/llvm/Support/FormatVariadicDetails.h
...

This requires duplicating the file_t typedef, which is unfortunate. I
sunk the choice of mapping mode down into the cpp file using variable
template specializations instead of class members in headers.
2020-02-29 12:30:23 -08:00
Lang Hames b7aa1cc3a4 [ORC] Remove the JITDylib::SymbolTableEntry::isInMaterializingState() method.
It was being used inconsistently. Uses have been replaced with direct checks
on the symbol state.
2020-02-25 16:44:12 -08:00
Benjamin Kramer 8c893cac3f [ORC] Remove spammy debug print 2020-02-24 12:10:13 +01:00
Lang Hames 1df947ab40 [ORC] Update LLJIT to automatically run specially named initializer functions.
The GenericLLVMIRPlatformSupport class runs a transform on all LLVM IR added to
the LLJIT instance to replace instances of llvm.global_ctors with a specially
named function that runs the corresponing static initializers (See
(GlobalCtorDtorScraper from lib/ExecutionEngine/Orc/LLJIT.cpp). This patch
updates the GenericIRPlatform class to check for this specially named function
in other materialization units that are added to the JIT and, if found, add
the function to the initializer work queue. Doing this allows object files
that were compiled from IR and cached to be reloaded in subsequent JIT sessions
without their initializers being skipped.

To enable testing this patch also updates the lli tool's -jit-kind=orc-lazy mode
to respect the -enable-cache-manager and -object-cache-dir options, and modifies
the CompileOnDemandLayer to rename extracted submodules to include a hash of the
names of their symbol definitions. This allows a simple object caching scheme
based on module names (which was already implemented in lli) to work with the
lazy JIT.
2020-02-22 11:49:14 -08:00
Lang Hames 81726894d3 [ORC] Add errors for missing and extraneous symbol definitions.
This patch adds new errors and error checking to the ObjectLinkingLayer to
catch cases where a compiled or loaded object either:
(1) Contains definitions not covered by its responsibility set, or
(2) Is missing definitions that are covered by its responsibility set.

Proir to this patch providing the correct set of definitions was treated as
an API contract requirement, however this requires that the client be confident
in the correctness of the whole compiler / object-cache pipeline and results
in difficult-to-debug assertions upon failure. Treating this as a recoverable
error results in clearer diagnostics.

The performance overhead of this check is one comparison of densemap keys
(symbol string pointers) per linking object, which is minimal. If this overhead
ever becomes a problem we can add the check under a flag that can be turned off
if the client fully trusts the rest of the pipeline.
2020-02-22 11:49:14 -08:00
Hans Wennborg 1f984c83a4 Add #include <condition_variable> to fix build after 85fb997659
See https://reviews.llvm.org/D74300#1884614
2020-02-20 16:36:19 +01:00
Lang Hames 63d0932c35 [ORC] Fix a missing move. 2020-02-19 14:27:31 -08:00
Lang Hames 85fb997659 [ORC] Add generic initializer/deinitializer support.
Initializers and deinitializers are used to implement C++ static constructors
and destructors, runtime registration for some languages (e.g. with the
Objective-C runtime for Objective-C/C++ code) and other tasks that would
typically be performed when a shared-object/dylib is loaded or unloaded by a
statically compiled program.

MCJIT and ORC have historically provided limited support for discovering and
running initializers/deinitializers by scanning the llvm.global_ctors and
llvm.global_dtors variables and recording the functions to be run. This approach
suffers from several drawbacks: (1) It only works for IR inputs, not for object
files (including cached JIT'd objects). (2) It only works for initializers
described by llvm.global_ctors and llvm.global_dtors, however not all
initializers are described in this way (Objective-C, for example, describes
initializers via specially named metadata sections). (3) To make the
initializer/deinitializer functions described by llvm.global_ctors and
llvm.global_dtors searchable they must be promoted to extern linkage, polluting
the JIT symbol table (extra care must be taken to ensure this promotion does
not result in symbol name clashes).

This patch introduces several interdependent changes to ORCv2 to support the
construction of new initialization schemes, and includes an implementation of a
backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a
MachO specific scheme that handles Objective-C runtime registration (if the
Objective-C runtime is available) enabling execution of LLVM IR compiled from
Objective-C and Swift.

The major changes included in this patch are:

(1) The MaterializationUnit and MaterializationResponsibility classes are
extended to describe an optional "initializer" symbol for the module (see the
getInitializerSymbol method on each class). The presence or absence of this
symbol indicates whether the module contains any initializers or
deinitializers. The initializer symbol otherwise behaves like any other:
searching for it triggers materialization.

(2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h
which provides the following callback interface:

  - Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols
    in JITDylibs upon creation. E.g. __dso_handle.

  - Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally
    used to record initializer symbols.

  - Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform
    that a module is being removed.

  Platform implementations can use these callbacks to track outstanding
initializers and implement a platform-specific approach for executing them. For
example, the MachOPlatform installs a plugin in the JIT linker to scan for both
__mod_inits sections (for C++ static constructors) and ObjC metadata sections.
If discovered, these are processed in the usual platform order: Objective-C
registration is carried out first, then static initializers are executed,
ensuring that calls to Objective-C from static initializers will be safe.

This patch updates LLJIT to use the new scheme for initialization. Two
LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO
platform. The GenericIR platform implements a modified version of the previous
llvm.global-ctor scraping scheme to provide support for Windows and
Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO
specific initialization as described above.

Reviewers: sgraenitz, dblaikie

Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74300
2020-02-19 13:59:32 -08:00
Alexandre Ganea 8404aeb56a [Support] On Windows, ensure hardware_concurrency() extends to all CPU sockets and all NUMA groups
The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket.

== Background ==
Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads.

By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to.

This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market.

== The problem ==
The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std:🧵:hardware_concurrency() -- which can only return processors from the current "processor group".

== The changes in this patch ==
To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO).

When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead.
The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used.

When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once.

Differential Revision: https://reviews.llvm.org/D71775
2020-02-14 10:24:22 -05:00
Lang Hames ca6f58486f [ORC] Fix symbol dependence propagation algorithm in ObjectLinkingLayer.
ObjectLinkingLayer was not correctly propagating dependencies through local
symbols within an object. This could cause symbol lookup to return before a
searched-for symbol is ready if the following conditions are met:
(1) The definition of the symbol being searched for transitively depends on a
    local symbol within the same object, and that local symbol in turn
    transitively depends on an external symbol provided by some other module
    in the JIT.
(2) Concurrent compilation is enabled.
(3) Thread scheduling causes the lookup of the searched-for symbol to return
    before all transitive dependencies of the looked-up symbol are emitted.

This bug was found by inspection and has not been observed in practice.

A jitlink test case has been added to verify that symbol dependencies are
correctly propagated through local symbol definitions.
2020-02-11 12:56:41 -08:00
Lang Hames 86787f159a [ORC] Add debug logging to JITDylib::addDependencies. 2020-02-11 12:56:40 -08:00
Bill Wendling c55cf4afa9 Revert "Remove redundant "std::move"s in return statements"
The build failed with

  error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a793.
2020-02-10 07:07:40 -08:00
Bill Wendling 1c2241a793 Remove redundant "std::move"s in return statements 2020-02-10 06:39:44 -08:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Guillaume Chatelet 805c157e8a [Alignment][NFC] Deprecate Align::None()
Summary:
This is a follow up on https://reviews.llvm.org/D71473#inline-647262.
There's a caveat here that `Align(1)` relies on the compiler understanding of `Log2_64` implementation to produce good code. One could use `Align()` as a replacement but I believe it is less clear that the alignment is one in that case.

Reviewers: xbolva00, courbet, bollu

Subscribers: arsenm, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, hiraditya, kbarton, jrtc27, atanasyan, jsji, Jim, kerbowa, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D73099
2020-01-24 12:53:58 +01:00
Lang Hames e0a6093a74 [ORC] Fix a missing move in ce2207abaf.
This should fix the build failure at
http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/32524
and others.
2020-01-21 20:14:50 -08:00
Lang Hames ce2207abaf [ORC] Add support for emulated TLS to ORCv2.
This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces
IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The
ManglingOptions struct defines the emulated-TLS state (via a bool member,
EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The
IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the
CompileFunction typedef used to), but adds a method to return the
IRCompileLayer::ManglingOptions that the compiler will use.

These changes allow us to correctly determine the symbols that will be produced
when a thread local global variable defined at the IR level is compiled with or
without emulated TLS. This is required for ORCv2, where MaterializationUnits
must declare their interface up-front.

Most ORCv2 clients should not require any changes. Clients writing custom IR
compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler,
rather than an IRCompileLayer::CompileFunction, however this should be a
straightforward change (see modifications to CompileUtils.* in this patch for an
example).
2020-01-21 19:55:33 -08:00
Lang Hames 84217ad661 [ORC] Add weak symbol support to defineMaterializing, fix for PR40074.
The MaterializationResponsibility::defineMaterializing method allows clients to
add new definitions that are in the process of being materialized to the JIT.
This patch adds support to defineMaterializing for symbols with weak linkage
where the new definitions may be rejected if another materializer concurrently
defines the same symbol. If a weak symbol is rejected it will not be added to
the MaterializationResponsibility's responsibility set. Clients can check for
membership in the responsibility set via the
MaterializationResponsibility::getSymbols() method before resolving any
such weak symbols.

This patch also adds code to RTDyldObjectLinkingLayer to tag COFF comdat symbols
introduced during codegen as weak, on the assumption that these are COFF comdat
constants. This fixes http://llvm.org/PR40074.
2020-01-19 10:46:07 -08:00
Lang Hames c75180258e [ORC] Set setCloneToNewContextOnEmit on LLJIT's transform layer when needed.
Based on Don Hinton's patch in https://reviews.llvm.org/D72406. This feature
was accidentally left out of e9e26c01cd, and
would have pessimized concurrent compilation in the default case.

Thanks for spotting this Don!
2020-01-15 10:22:57 -08:00
Lang Hames e9e26c01cd [ORC] Simplify use of lazyReexports with LLJIT.
This patch makes the target triple available via the LLJIT interface, and moves
the IRTransformLayer from LLLazyJIT down into LLJIT. Together these changes make
it easier to use the lazyReexports utility with LLJIT, and to apply IR
transforms to code as it is compiled in LLJIT (rather than requiring transforms
to be applied manually before code is added). An code example is added in
llvm/examples/LLJITExamples/LLJITWithLazyReexports
2020-01-15 08:02:53 -08:00
Lang Hames d2fabd7006 [ORC] Update lazyReexports to support aliases with different symbol names.
A bug in the existing implementation meant that lazyReexports would not work if
the aliased name differed from the alias's name, i.e. all lazy reexports had to
be of the form (lib1, name) -> (lib2, name). This patch fixes the issue by
capturing the alias's name in the NotifyResolved callback. To simplify this
capture, and the LazyCallThroughManager code in general, the NotifyResolved
callback is updated to use llvm::unique_function rather than a custom class.

No test case yet: This can only be tested at runtime, and the only in-tree
client (lli) always uses aliases with matching names. I will add a new LLJIT
example shortly that will directly test the lazyReexports API and the
non-trivial alias use case.
2020-01-15 08:02:53 -08:00
Lang Hames 2cdb18afda [ORC] Fix argv handling in runAsMain / lli.
This fixes an off-by-one error in the argc value computed by runAsMain, and
switches lli back to using the input bitcode (rather than the string "lli") as
the effective program name.

Thanks to Stefan Graenitz for spotting the bug.
2020-01-11 13:03:38 -08:00
Stefan Gränitz c7191d3acd [NFC][ORC] Fix typos and whitespaces in comments 2020-01-03 21:54:03 +01:00
Mark de Wever 8dc7b982b4 [NFC] Fixes -Wrange-loop-analysis warnings
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

Differential Revision: https://reviews.llvm.org/D71857
2020-01-01 20:01:37 +01:00
Lang Hames 9f4f237e29 [ORC] De-register eh-frames in the RTDyldObjectLinkingLayer destructor.
This matches the behavior of the legacy layer, which automatically deregistered
frames.
2019-12-20 21:10:49 -08:00
Lang Hames 07ac3145cc [Orc][LLJIT] Re-apply 298e183e81 (use JITLink for LLJIT where supported).
Patch d9220b580b fixed the underlying issue that casued 298e183e81 to fail.
2019-12-19 20:42:26 -08:00
Lang Hames 5ea91bea15 Revert "[Orc][LLJIT] Use JITLink even if a custom JITTargetMachineBuilder is supplied."
This reverts commit 298e183e81.

This commit caused some build failures -- reverting while I investigate.
2019-12-18 15:13:35 -08:00
Lang Hames 298e183e81 [Orc][LLJIT] Use JITLink even if a custom JITTargetMachineBuilder is supplied.
LLJITBuilder will now use JITLink on supported platforms even if a custom
JITTargetMachineBuilder is supplied, provided that neither the code model,
nor the relocation model, nor the ObjectLinkingLayerCreator is set.
2019-12-18 14:17:25 -08:00
Lang Hames 67a1b7f053 [Orc][LLJIT] Automatically use JITLink for LLJIT on supported platforms.
JITLink (which underlies ObjectLinkingLayer) is a replacement for RuntimeDyld.
It supports the native code model, and linker plugins that enable a wider range
of features than RuntimeDyld.

Currently only enabled for MachO/x86-64 and MachO/arm64. New architectures will
be added as JITLink support for them is developed.
2019-12-15 21:57:10 -08:00
Lang Hames c0143f37da [ORC] Make ObjectLinkingLayer own its jitlink::MemoryManager.
This relieves ObjectLinkingLayer clients of the responsibility of holding the
memory manager. This makes it easier to select between RTDyldObjectLinkingLayer
(which already owned its memory manager factory) and ObjectLinkingLayer at
runtime as clients aren't required to hold a jitlink::MemoryManager field just
in case ObjectLinkingLayer is selected.
2019-12-15 17:35:52 -08:00
Lang Hames 4fc68b9b7f [ORC] Remove the automagic Main JITDylib fram ExecutionSession.
This patch removes the magic "main" JITDylib from ExecutionEngine. The main
JITDylib was created automatically at ExecutionSession construction time, and
all subsequently created JITDylibs were added to the main JITDylib's
links-against list by default. This saves a couple of lines of boilerplate for
simple JIT setups, but this isn't worth introducing magical behavior for.

ORCv2 clients should now construct their own main JITDylib using
ExecutionSession::createJITDylib and set up its linkages manually using
JITDylib::setSearchOrder (or related methods in JITDylib).
2019-12-05 01:36:49 -08:00
Lang Hames ece8fed609 [ORC] Add a runAsMain utility function to ExecutionUtils.
The runAsMain function takes a pointer to a function with a standard C main
signature, int(*)(int, char*[]), and invokes it using the given arguments and
program name. The arguments are copied into writable temporary storage as
required by the C and C++ specifications, so runAsMain safe to use when calling
main functions that modify their arguments in-place.

This patch also uses the new runAsMain function to replace hand-rolled versions
in lli, llvm-jitlink, and the SpeculativeJIT example.
2019-12-02 01:52:52 -08:00
Lang Hames 5c05b4a279 [Orc] Add setters for target options and features to JITTargetMachineBuilder.
Also remove redundant feature initialization steps from the detectHost method.
2019-12-02 01:52:51 -08:00
Lang Hames 674df13b5f [ORC][JITLink] Add support for weak references, and improve handling of static
libraries.

This patch substantially updates ORCv2's lookup API in order to support weak
references, and to better support static archives. Key changes:

-- Each symbol being looked for is now associated with a SymbolLookupFlags
   value. If the associated value is SymbolLookupFlags::RequiredSymbol then
   the symbol must be defined in one of the JITDylibs being searched (or be
   able to be generated in one of these JITDylibs via an attached definition
   generator) or the lookup will fail with an error. If the associated value is
   SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be
   undefined, in which case it will simply not appear in the resulting
   SymbolMap if the rest of the lookup succeeds.

   Since lookup now requires these flags for each symbol, the lookup method now
   takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet.
   SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are
   responsible for ensuring that the set property (i.e. unique elements) holds,
   though this is usually simple and SymbolLookupSet provides convenience
   methods to support this.

-- Lookups now have an associated LookupKind value, which is either
   LookupKind::Static or LookupKind::DLSym. Definition generators can inspect
   the lookup kind when determining whether or not to generate new definitions.
   The StaticLibraryDefinitionGenerator is updated to only pull in new objects
   from the archive if the lookup kind is Static. This allows lookup to be
   re-used to emulate dlsym for JIT'd symbols without pulling in new objects
   from archives (which would not happen in a normal dlsym call).

-- JITLink is updated to allow externals to be assigned weak linkage, and
   weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value
   for lookups. Unresolved weak references will be assigned the default value of
   zero.

Since this patch was modifying the lookup API anyway, it alo replaces all of the
"MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for
readability. If a JITDylib's associated value is
JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only
match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's
associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will
match against any symbol defined in the JITDylib.
2019-11-28 13:30:49 -08:00
Tom Stellard ab411801b8 [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO.  I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so.  Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:

1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so.  This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.

With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.

2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set.  This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.

I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:

- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON

Reviewers: beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70179
2019-11-21 10:48:08 -08:00
Hans Wennborg c42e385135 Fix GCC -Wcast-qual warnings 2019-11-15 09:49:06 +01:00
Hans Wennborg 04dcb8009f GCC 5.3 build fix
It was failing with

  llvm/lib/ExecutionEngine/Orc/DebugUtils.cpp:56:10:
  error: could not convert ‘Obj’ from ‘std::unique_ptr<llvm::MemoryBuffer>’
  to ‘llvm::Expected<std::unique_ptr<llvm::MemoryBuffer> >’
     return Obj;
            ^
2019-11-15 09:49:06 +01:00
Lang Hames 16f38dda29 [ORC] Add a utility to support dumping JIT'd objects to disk for debugging.
Adds a DumpObjects utility that can be used to dump JIT'd objects to disk.
Instances of DebugObjects may be used by ObjectTransformLayer as no-op
transforms.

This patch also adds an ObjectTransformLayer to LLJIT and an example of how
to use this utility to dump JIT'd objects in LLJIT.
2019-11-14 21:27:19 -08:00
Alexandre Ganea 007d173e2e [Orc] Fix iterator usage after remove
Differential Revision: https://reviews.llvm.org/D69805
2019-11-06 17:17:27 -05:00
Chris Bieneman a34680a33e Break out OrcError and RPC
Summary:
When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more.

This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory.

With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport.

Reviewers: lhames

Reviewed By: lhames

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68732
2019-10-29 17:31:28 -07:00
Reid Kleckner 90c64a3456 Move endian constant from Host.h to SwapByteOrder.h, prune include
Works on this dependency chain:
  ArrayRef.h ->
  Hashing.h -> --CUT--
  Host.h ->
  StringMap.h / StringRef.h

ArrayRef is very popular, but Host.h is rarely needed. Move the
IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are
more likely to need it.

llvm-svn: 375316
2019-10-19 00:48:11 +00:00
Lang Hames a98546ebcd [Orc] Add a method for ObjectLinkingLayer to return ownership of object buffers.
RTDyldObjectLinkingLayer allowed clients to register a NotifyEmitted function to
reclaim ownership of object buffers once they had been linked. This patch adds
similar functionality to ObjectLinkingLayer: Clients can now optionally call the
ObjectLinkingLayer::setReturnObjectBuffer method to register a function that
will be called when discarding object buffers. If set, this function will be
called to return ownership of the object regardless of whether the link
succeeded or failed.

Use cases for this function include debug dumping (it provides a way to dump
all objects linked into JIT'd code) and object re-use (e.g. storing an
object in a cache).

llvm-svn: 374951
2019-10-15 21:41:12 +00:00
Guillaume Chatelet 0e62011df8 [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits

Tags: #llvm

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

llvm-svn: 374880
2019-10-15 11:24:36 +00:00
Jordan Rose fdaa742174 Second attempt to add iterator_range::empty()
Doing this makes MSVC complain that `empty(someRange)` could refer to
either C++17's std::empty or LLVM's llvm::empty, which previously we
avoided via SFINAE because std::empty is defined in terms of an empty
member rather than begin and end. So, switch callers over to the new
method as it is added.

https://reviews.llvm.org/D68439

llvm-svn: 373935
2019-10-07 18:14:24 +00:00
Lang Hames 4e920e58e6 [JITLink] Switch from an atom-based model to a "blocks and symbols" model.
In the Atom model the symbols, content and relocations of a relocatable object
file are represented as a graph of atoms, where each Atom represents a
contiguous block of content with a single name (or no name at all if the
content is anonymous), and where edges between Atoms represent relocations.
If more than one symbol is associated with a contiguous block of content then
the content is broken into multiple atoms and layout constraints (represented by
edges) are introduced to ensure that the content remains effectively contiguous.
These layout constraints must be kept in mind when examining the content
associated with a symbol (it may be spread over multiple atoms) or when applying
certain relocation types (e.g. MachO subtractors).

This patch replaces the Atom model in JITLink with a blocks-and-symbols model.
The blocks-and-symbols model represents relocatable object files as bipartite
graphs, with one set of nodes representing contiguous content (Blocks) and
another representing named or anonymous locations (Symbols) within a Block.
Relocations are represented as edges from Blocks to Symbols. This scheme
removes layout constraints (simplifying handling of MachO alt-entry symbols,
and hopefully ELF sections at some point in the future) and simplifies some
relocation logic.

llvm-svn: 373689
2019-10-04 03:55:26 +00:00
Simon Pilgrim 7efa6e3126 [Orc] Silence static analyzer dyn_cast<ConstantInt> null dereference warning. NFCI.
llvm-svn: 372746
2019-09-24 12:43:55 +00:00
Sanjoy Das fe4dc2e713 Add dependency from Orc to Passes
Summary: Orc uses registerFunctionAnalyses that's defined in Passes.

Reviewers: dblaikie

Subscribers: mcrosier, bixia, llvm-commits

Tags: #llvm

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

llvm-svn: 371898
2019-09-13 21:07:56 +00:00
Benjamin Kramer 6baaa4be78 [Orc] Roll back ThreadPool to std::function
MSVC doesn't allow move-only types in std::packaged_task. Boo.

llvm-svn: 371844
2019-09-13 11:59:51 +00:00
Benjamin Kramer ce74c3b19f [Orc] Address the remaining move-capture FIXMEs
This required spreading unique_function a bit more, which I think is a
good thing.

llvm-svn: 371843
2019-09-13 11:35:33 +00:00
Tim Northover f1c2892912 AArch64: support arm64_32, an ILP32 slice for watchOS.
This is the main CodeGen patch to support the arm64_32 watchOS ABI in LLVM.
FastISel is mostly disabled for now since it would generate incorrect code for
ILP32.

llvm-svn: 371722
2019-09-12 10:22:23 +00:00
Praveen Velliengiri 3b1b56d3fb [ORCv2] - New Speculate Query Implementation
Summary:
This patch introduces, SequenceBBQuery - new heuristic to find likely next callable functions it tries to find the blocks with calls in order of execution sequence of Blocks.

It still uses BlockFrequencyAnalysis to find high frequency blocks. For a handful of hottest blocks (plan to customize), the algorithm traverse and discovered the caller blocks along the way to Entry Basic Block and Exit Basic Block. It uses Block Hint, to stop traversing the already visited blocks in both direction. It implicitly assumes that once the block is visited during discovering entry or exit nodes, revisiting them again does not add much. It also branch probability info (cached result) to traverse only hot edges (planned to customize) from hot blocks. Without BPI, the algorithm mostly return's all the blocks in the CFG with calls.

It also changes the heuristic queries, so they don't maintain states. Hence it is safe to call from multiple threads.

It also implements, new instrumentation to avoid jumping into JIT on every call to the function with the help _orc_speculate.decision.block and _orc_speculate.block.

"Speculator Registration Mechanism is also changed" - kudos to @lhames

Open to review, mostly looking to change implementation of SequeceBBQuery heuristics with good data structure choices.

Reviewers: lhames, dblaikie

Reviewed By: lhames

Subscribers: mgorny, hiraditya, mgrang, llvm-commits, lhames

Tags: #speculative_compilation_in_orc, #llvm

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

llvm-svn: 370092
2019-08-27 18:23:36 +00:00
Lang Hames c48f1f6da6 [JITLink][ORC] Track eh-frame section size for registration/deregistration.
On MachO, processing of the eh-frame section should stop if the end of the
__eh_frame section is reached, regardless of whether or not there is a null CFI
length field at the end of the section. This patch tracks the eh-frame section
size and threads it through the appropriate APIs so that processing can be
terminated correctly.

No testcase yet: This patch is all API plumbing (rather than modification of
linked memory) which the existing infrastructure does not provide a way of
testing. Committing without a testcase until I have an idea of how to write
one.

llvm-svn: 370074
2019-08-27 15:50:32 +00:00
Lang Hames 8853ac7e02 [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.
In r369808 the failure scheme for ORC symbols was changed to make
MaterializationResponsibility objects responsible for failing the symbols
they represented. This simplifies error logic in the case where symbols are
still covered by a MaterializationResponsibility, but left a gap in error
handling: Symbols that have been emitted but are not yet ready (due to a
dependence on some unemitted symbol) are not covered by a
MaterializationResponsibility object. Under the scheme introduced in r369808
such symbols would be moved to the error state, but queries on those symbols
were never notified. This led to deadlocks when such symbols were failed.

This commit updates error logic to immediately fail queries on any symbol that
has already been emitted if one of its dependencies fails.

llvm-svn: 369976
2019-08-26 21:42:51 +00:00
Lang Hames 8ec9661870 [ORC] Fix an overly aggressive assert.
Symbols that have not been queried will not have MaterializingInfo entries,
so remove the assert that all failed symbols should have these entries.
Also updates the loop to only remove entries that were found earlier.

llvm-svn: 369975
2019-08-26 21:42:47 +00:00
Lang Hames 7371fb4229 [ORC] Remove query dependencies when symbols are resolved.
If the dependencies are not removed then a late failure (one symbol covered by
the query failing after others have already been resolved) can result in an
attempt to detach the query from already finalized symbol, resulting in an
assert/crash. This patch fixes the issue by removing query dependencies in
JITDylib::resolve for symbols that meet the required state.

llvm-svn: 369809
2019-08-23 20:37:32 +00:00
Lang Hames e00585c77c [ORC] Fix a FIXME: Propagate errors to dependencies.
When symbols are failed (via MaterializationResponsibility::failMaterialization)
any symbols depending on them will now be moved to an error state. Attempting
to resolve or emit a symbol in the error state (via the notifyResolved or
notifyEmitted methods on MaterializationResponsibility) will result in an error.
If notifyResolved or notifyEmitted return an error due to failure of a
dependence then the caller should log or discard the error and call
failMaterialization to propagate the failure to any queries waiting on the
symbols being resolved/emitted (plus their dependencies).

llvm-svn: 369808
2019-08-23 20:37:31 +00:00
Hubert Tong 71974b5175 [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFC
Summary:
rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses.
In particular, symbols defined in LLVMPasses that are referenced by the
destructor of `PassBuilder` are now referenced by LLVMOrcJIT through
`Speculation.cpp.o`.

We believe that referencing symbols defined in LLVMPasses in the
destructor of `PassBuilder` is valid, and that adding to the set of such
symbols is legitimate. To support such cases, this patch adds LLVMPasses
to the set of libraries being linked when linking in LLVMOrcJIT causes
such symbols from LLVMPasses to be referenced.

Reviewers: Whitney, anhtuyen, pree-jackie

Reviewed By: pree-jackie

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

llvm-svn: 369310
2019-08-19 23:12:48 +00:00
Matthias Gehre 5b3275e56f [ORC] fix use-after-free detected by -Wreturn-stack-address
Summary:
llvm/lib/ExecutionEngine/Orc/Layer.cpp:53:12: warning: returning address of local temporary object [-Wreturn-stack-address]

In
```
StringRef IRMaterializationUnit::getName() const {
[...]
     return TSM.withModuleDo(
        [](const Module &M) { return M.getModuleIdentifier(); });
```
`getModuleIdentifier()` returns a `const std::string &`, but the implicit return type
of the lambda is `std::string` by value, and thus the returned `StringRef` refers
to a temporary `std::string`.

Detect by annotating `llvm::StringRef` with `[[gsl::Pointer]]`.

Reviewers: lhames, sgraenitz

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 369306
2019-08-19 21:59:44 +00:00
Lang Hames 9bb9a0c10b [ORC] Remove some stray debugging output accidentally left in r368707
llvm-svn: 369141
2019-08-16 19:33:37 +00:00
Jonas Devlieghere 0eaee545ee [llvm] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013
2019-08-15 15:54:37 +00:00
Lang Hames 52a34a78d9 [ORC] Refactor definition-generation, add a generator for static libraries.
This patch replaces the JITDylib::DefinitionGenerator typedef with a class of
the same name, and adds support for attaching a sequence of DefinitionGeneration
objects to a JITDylib.

This patch also adds a new definition generator,
StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static
library to a JITDylib. An object from the static library will be added (via
a supplied ObjectLayer reference) whenever a symbol from that object is
referenced.

To enable testing, lli is updated to add support for the --extra-archive option
when running in -jit-kind=orc-lazy mode.

llvm-svn: 368707
2019-08-13 16:05:18 +00:00
Eric Christopher 4acb4ee767 Move findBBwithCalls to the file it's used in to avoid unused function
warnings.

llvm-svn: 368636
2019-08-13 00:05:01 +00:00
Diego Caballero 8bac17709e Re-land D65760/r367944
Fixed most vexing parse ambiguation.

llvm-svn: 368055
2019-08-06 16:24:17 +00:00
Puyan Lotfi 37fe40c330 Reverting D65760/r367944 due to buildbot failure.
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/15952/steps/build/logs/stdio

JITTargetMachineBuilder.cpp fails to build.

llvm-svn: 367954
2019-08-05 23:47:07 +00:00
Diego Caballero 1647758882 [ORC] Add CPU name and sub-target features to detectHost
This commit adds host CPU name and sub-target features to the
`JITTargetMachineBuilder` created by `JITTargetMachineBuilder::detectHost()`.

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

llvm-svn: 367944
2019-08-05 23:02:12 +00:00
Lang Hames 1707735fa4 [ORC] Work around broken GCC/libstdc++ by adding an explicit conversion.
This should fix the bots that have been failing due to r367712.

llvm-svn: 367921
2019-08-05 20:30:35 +00:00
Praveen Velliengiri f5c40cb900 Speculative Compilation
[ORC] Remove Speculator Variants for Different Program Representations

[ORC] Block Freq Analysis

Speculative Compilation with Naive Block Frequency

Add Applications to OrcSpeculation

ORC v2 with Block Freq Query & Example

Deleted BenchMark Programs

Signed-off-by: preejackie <praveenvelliengiri@gmail.com>

ORCv2 comments resolved

[ORCV2] NFC

ORCv2 NFC

[ORCv2] Speculative compilation - CFGWalkQuery

ORCv2 Adapting IRSpeculationLayer to new locking scheme

llvm-svn: 367756
2019-08-03 14:42:13 +00:00
Lang Hames 10430f4174 [ORC] Remove a dead method.
llvm-svn: 367716
2019-08-02 20:09:30 +00:00
Lang Hames cb391279b4 [ORC] Turn on symbol-flags overrides for LLJIT on Windows by default.
libObject does not apply the Exported flag to symbols in COFF object files,
which can lead to assertions when the symbol flags initially derived from
IR added to the JIT clash with the flags seen by the JIT linker. Both
RTDyldObjectLinkingLayer and ObjectLinkingLayer have a workaround for this:
they can be told to override the flags seen by the linker with the flags
attached to the materialization responsibility object that was passed down
to the linker. This patch modifies LLJIT's setup code to enable this override
by default on platforms where COFF is the default object format.

llvm-svn: 367712
2019-08-02 19:43:20 +00:00
Lang Hames 809e9d1efa [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
2019-08-02 15:21:37 +00:00
Lang Hames 9e52d0576a [ORC] Suppress an ORCv1 deprecation warning.
llvm-svn: 366485
2019-07-18 19:55:42 +00:00
Lang Hames 1716454027 [ORC] Add deprecation warnings to ORCv1 layers and utilities.
Summary:
ORCv1 is deprecated. The current aim is to remove it before the LLVM 10.0
release. This patch adds deprecation attributes to the ORCv1 layers and
utilities to warn clients of the change.

Reviewers: dblaikie, sgraenitz, AlexDenisov

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 366344
2019-07-17 16:40:52 +00:00
Lang Hames 843f198a83 [ORC] Add custom IR compiler configuration to LLJITBuilder to enable obj caches.
LLJITBuilder now has a setCompileFunctionCreator method which can be used to
construct a CompileFunction for the LLJIT instance being created. The motivating
use-case for this is supporting ObjectCaches, which can now be set up at
compile-function construction time. To demonstrate this an example project,
LLJITWithObjectCache, is included.

llvm-svn: 365671
2019-07-10 17:24:24 +00:00
Lang Hames f5a885fddd [JITLink][ORC] Add EHFrameRegistrar interface, use in EHFrameRegistrationPlugin.
Replaces direct calls to eh-frame registration with calls to methods on an
EHFrameRegistrar instance. This allows clients to substitute a registrar that
registers frames in a remote process via IPC/RPC.

llvm-svn: 365098
2019-07-04 00:05:12 +00:00
Lang Hames 2f8c6f9362 [ORC] Rename MaterializationResponsibility resolve and emit methods to
notifyResolved/notifyEmitted.

The 'notify' prefix better describes what these methods do: they update the JIT
symbol states and notify any pending queries that the 'resolved' and 'emitted'
states have been reached (rather than actually performing the resolution or
emission themselves). Since new states are going to be introduced in the near
future (to track symbol registration/initialization) it's worth changing the
convention pre-emptively to avoid further confusion.

llvm-svn: 363322
2019-06-13 20:11:23 +00:00
Lang Hames d4a8089f03 [ORC] Update symbol lookup to use a single callback with a required symbol state
rather than two callbacks.

The asynchronous lookup API (which the synchronous lookup API wraps for
convenience) used to take two callbacks: OnResolved (called once all requested
symbols had an address assigned) and OnReady to be called once all requested
symbols were safe to access). This patch updates the asynchronous lookup API to
take a single 'OnComplete' callback and a required state (SymbolState) to
determine when the callback should be made. This simplifies the common use case
(where the client is interested in a specific state) and will generalize neatly
as new states are introduced to track runtime initialization of symbols.

Clients who were making use of both callbacks in a single query will now need to
issue two queries (one for SymbolState::Resolved and another for
SymbolState::Ready). Synchronous lookup API clients who were explicitly passing
the WaitOnReady argument will now need neeed to pass a SymbolState instead (for
'WaitOnReady == true' use SymbolState::Ready, for 'WaitOnReady == false' use
SymbolState::Resolved). Synchronous lookup API clients who were using default
arugment values should see no change.

llvm-svn: 362832
2019-06-07 19:33:51 +00:00
Lang Hames eb5ee3004f [ORC] Track JIT symbol states more explicitly.
Prior to this patch, JITDylibs inferred symbol states (whether a symbol was
newly added, materializing, resolved, or ready to run) via a combination of (1)
bits in the JITSymbolFlags member, and (2) the state of some internal JITDylib
data structures. This patch explicitly tracks symbol states by adding a new
SymbolState member to the symbol table entries, and removing the 'Lazy' and
'Materializing' bits from JITSymbolFlags. This is a first step towards adding
additional states representing initialization phases (e.g. eh-frame registration,
registration with the language runtime, and static initialization).

llvm-svn: 361899
2019-05-28 23:35:44 +00:00
Lang Hames f088e195cc [ORC] Assert that JITDylibs have unique names.
Patch by Praveen Velliengiri. Thanks Praveen!

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

llvm-svn: 361215
2019-05-21 03:23:08 +00:00
Nick Desaulniers 28e351af2a [ORC] fix use-after-move. NFC
Summary:
scan-build flagged a potential use-after-move in debug builds.  It's not
safe that a moved from value contains anything but garbage.  Manually
DRY up these repeated expressions.

Reviewers: lhames

Reviewed By: lhames

Subscribers: hiraditya, llvm-commits, srhines

Tags: #llvm

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

llvm-svn: 361203
2019-05-20 22:17:43 +00:00
Lang Hames 0dcf69eb82 [ORC] Remove some unreachable code.
Fixes http://llvm.org/PR41662.

llvm-svn: 361199
2019-05-20 21:30:33 +00:00
Lang Hames c97b50e224 [ORC] Change handling for SymbolStringPtr tombstones and empty keys.
SymbolStringPtr used to use nullptr as its empty value and (since it performed
ref-count operations on any non-nullptr) a pointer to a special pool-entry
instance as its tombstone.

This commit changes the scheme to use two invalid pointer values as the empty
and tombstone values, and broadens the ref-count guard to prevent ref-counting
operations from being performed on these pointers. This should improve the
performance of SymbolStringPtrs used in DenseMaps/DenseSets, as ref counting
operations will no longer be performed on the tombstone.

llvm-svn: 360925
2019-05-16 18:29:34 +00:00
Lang Hames 5fa4e9d990 [ORC] Fix a formatting bug.
llvm-svn: 360382
2019-05-09 22:03:53 +00:00
Lang Hames e4b4ab6d26 [Support] Add error handling to sys::Process::getPageSize().
This patch changes the return type of sys::Process::getPageSize to
Expected<unsigned> to account for the fact that the underlying syscalls used to
obtain the page size may fail (see below).

For clients who use the page size as an optimization only this patch adds a new
method, getPageSizeEstimate, which calls through to getPageSize but discards
any error returned and substitues a "reasonable" page size estimate estimate
instead. All existing LLVM clients are updated to call getPageSizeEstimate
rather than getPageSize.

On Unix, sys::Process::getPageSize is implemented in terms of getpagesize or
sysconf, depending on which macros are set. The sysconf call is documented to
return -1 on failure. On Darwin getpagesize is implemented in terms of sysconf
and may also fail (though the manpage documentation does not mention this).
These failures have been observed in practice when highly restrictive sandbox
permissions have been applied. Without this patch, the result is that
getPageSize returns -1, which wreaks havoc on any subsequent code that was
assuming a sane page size value.

<rdar://problem/41654857>

Reviewers: dblaikie, echristo

Subscribers: kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 360221
2019-05-08 02:11:07 +00:00
Lang Hames 42a3b4ff0e [ORC] Pass object buffer ownership back in NotifyEmitted.
Clients who want to regain ownership of object buffers after they have been
linked may now use the NotifyEmitted callback for this purpose.

Note: Currently NotifyEmitted is only called if linking succeeds. If linking
fails the buffer is always discarded.

llvm-svn: 359735
2019-05-01 22:40:23 +00:00
Lang Hames 4637e15844 [ORC] Move SimpleCompiler/ConcurrentIRCompiler definitions into a .cpp file.
SimpleCompiler is no longer templated, so there's no reason for this code to be
in a header any more.

llvm-svn: 359626
2019-04-30 22:42:01 +00:00
Lang Hames b12867230c [ORC] Allow JITDylib definition generators to return Errors.
Background: A definition generator can be attached to a JITDylib to generate
new definitions in response to queries. For example: a generator that forwards
calls to dlsym can map symbols from a dynamic library into the JIT process on
demand.

If definition generation fails then the generator should be able to return an
error. This allows the JIT API to distinguish between the case where a
generator does not provide a definition, and the case where it was not able to
determine whether it provided a definition due to an error.

The immediate motivation for this is cross-process symbol lookups: If the
remote-lookup generator is attached to a JITDylib early in the search list, and
if a generator failure is misinterpreted as "no definition in this JITDylib" then
lookup may continue and bind to a different definition in a later JITDylib, which
is a bug.

llvm-svn: 359521
2019-04-30 00:03:26 +00:00
Lang Hames eb14dc7585 [ORC] Replace the LLJIT/LLLazyJIT Create methods with Builder utilities.
LLJITBuilder and LLLazyJITBuilder construct LLJIT and LLLazyJIT instances
respectively. Over time these will allow more configurable options to be
added while remaining easy to use in the default case, which for default
in-process JITing is now:

auto J = ExitOnErr(LLJITBuilder.create());

llvm-svn: 359511
2019-04-29 22:37:27 +00:00
Lang Hames a9fdf375b3 [ORC] Add a 'plugin' interface to ObjectLinkingLayer for events/configuration.
ObjectLinkingLayer::Plugin provides event notifications when objects are loaded,
emitted, and removed. It also provides a modifyPassConfig callback that allows
plugins to modify the JITLink pass configuration.

This patch moves eh-frame registration into its own plugin, and teaches
llvm-jitlink to only add that plugin when performing execution runs on
non-Windows platforms. This should allow us to re-enable the test case that was
removed in r359198.

llvm-svn: 359357
2019-04-26 22:58:39 +00:00
Lang Hames 4f71049a39 [ORC] Remove symbols from dependency lists when failing materialization.
When failing materialization of a symbol X, remove X from the dependants list
of any of X's dependencies. This ensures that when X's dependencies are
emitted (or fail themselves) they do not try to access the no-longer-existing
MaterializationInfo for X.

llvm-svn: 359252
2019-04-25 23:31:33 +00:00
Lang Hames 1233c15be5 [JITLink] Remove a lot of reduntant 'JITLink_' prefixes. NFC.
llvm-svn: 358869
2019-04-22 03:03:09 +00:00
Lang Hames 5004abcd86 [JITLink][ORC] Add JITLink to the list of dependencies for ORC.
The new ObjectLinkingLayer in ORC depends on JITLink.

This should fix the build error at
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/9621

llvm-svn: 358832
2019-04-20 22:15:57 +00:00
Lang Hames 11c8dfa583 Initial implementation of JITLink - A replacement for RuntimeDyld.
Summary:

JITLink is a jit-linker that performs the same high-level task as RuntimeDyld:
it parses relocatable object files and makes their contents runnable in a target
process.

JITLink aims to improve on RuntimeDyld in several ways:

(1) A clear design intended to maximize code-sharing while minimizing coupling.

RuntimeDyld has been developed in an ad-hoc fashion for a number of years and
this had led to intermingling of code for multiple architectures (e.g. in
RuntimeDyldELF::processRelocationRef) in a way that makes the code more
difficult to read, reason about, extend. JITLink is designed to isolate
format and architecture specific code, while still sharing generic code.

(2) Support for native code models.

RuntimeDyld required the use of large code models (where calls to external
functions are made indirectly via registers) for many of platforms due to its
restrictive model for stub generation (one "stub" per symbol). JITLink allows
arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be
added naturally.

(3) Native support for asynchronous linking.

JITLink uses asynchronous calls for symbol resolution and finalization: these
callbacks are passed a continuation function that they must call to complete the
linker's work. This allows for cleaner interoperation with the new concurrent
ORC JIT APIs, while still being easily implementable in synchronous style if
asynchrony is not needed.

To maximise sharing, the design has a hierarchy of common code:

(1) Generic atom-graph data structure and algorithms (e.g. dead stripping and
 |  memory allocation) that are intended to be shared by all architectures.
 |
 + -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to
       |  atom-graph parsing.
       |
       + -- (3) Architecture specific code that uses (1) and (2). E.g.
                JITLinkerMachO_x86_64, which adds x86-64 specific relocation
                support to (2) to build and patch up the atom graph.

To support asynchronous symbol resolution and finalization, the callbacks for
these operations take continuations as arguments:

  using JITLinkAsyncLookupContinuation =
      std::function<void(Expected<AsyncLookupResult> LR)>;

  using JITLinkAsyncLookupFunction =
      std::function<void(const DenseSet<StringRef> &Symbols,
                         JITLinkAsyncLookupContinuation LookupContinuation)>;

  using FinalizeContinuation = std::function<void(Error)>;

  virtual void finalizeAsync(FinalizeContinuation OnFinalize);

In addition to its headline features, JITLink also makes other improvements:

  - Dead stripping support: symbols that are not used (e.g. redundant ODR
    definitions) are discarded, and take up no memory in the target process
    (In contrast, RuntimeDyld supported pointer equality for weak definitions,
    but the redundant definitions stayed resident in memory).

  - Improved exception handling support. JITLink provides a much more extensive
    eh-frame parser than RuntimeDyld, and is able to correctly fix up many
    eh-frame sections that RuntimeDyld currently (silently) fails on.

  - More extensive validation and error handling throughout.

This initial patch supports linking MachO/x86-64 only. Work on support for
other architectures and formats will happen in-tree.

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

llvm-svn: 358818
2019-04-20 17:10:34 +00:00
James Y Knight 14359ef1b6 [opaque pointer types] Pass value type to LoadInst creation.
This cleans up all LoadInst creation in LLVM to explicitly pass the
value type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352911
2019-02-01 20:44:24 +00:00
James Y Knight 7976eb5838 [opaque pointer types] Pass function types to CallInst creation.
This cleans up all CallInst creation in LLVM to explicitly pass a
function type rather than deriving it from the pointer's element-type.

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

llvm-svn: 352909
2019-02-01 20:43:25 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Lang Hames 199a00c3a2 Revert r351138 "[ORC] Move ORC Core symbol map and set types into their own
header: CoreTypes.h."

This commit broke some bots. Reverting while I investigate.

llvm-svn: 351195
2019-01-15 15:21:13 +00:00
Lang Hames ed2df18a48 [ORC] Move ORC Core symbol map and set types into their own header: CoreTypes.h.
This will allow other utilities (including a future RuntimeDyld replacement) to
use these types without pulling in the major Core types (JITDylib, etc.).

llvm-svn: 351138
2019-01-14 23:49:13 +00:00
Simon Atanasyan 789f4154db [ORC][MIPS] Fill delay-slot after `jr` instruction
MIPS `jr` instruction uses a delay-slot. To escape execution of
arbitrary instruction we should either fill the delay-slot by `nop`
instruction or swap `jr` instruction and logically preceding
instruction. This fix implements the second method to generate a bit
more effective code.

llvm-svn: 351001
2019-01-12 11:12:08 +00:00
Simon Atanasyan f903f782e7 [ORC][MIPS] Setup t9 register and call function through this register
MIPS ABI states that every function must be called through jalr $t9. In
other words, a function expect that t9 register points to the beginning
of its code. A function uses this register to calculate offset to the
Global Offset Table and save it to the `gp` register.
```
lui   $gp, %hi(_gp_disp)
addiu $gp, %lo(_gp_disp)
addu  $gp, $gp, $t9
```

If `t9` and as a result `$gp` point to the wrong place the following code
loads incorrect value from GOT and passes control to invalid code.
```
lw    $v0,%call16(foo)($gp)
jalr  $t9
```

OrcMips32 and OrcMips64 writeResolverCode methods pass control to the
resolved address, but do not setup `$t9` before the call. The `t9` holds
value of the beginning of `resolver` code so any attempts to call
routines via GOT failed.

This change fixes the problem. The `OrcLazy/hidden-visibility.ll` test
starts to pass correctly. Before the change it fails on MIPS because the
`exitOnLazyCallThroughFailure` called from the resolver code could not
call libc routine `exit` via GOT.

Differential Revision: http://reviews.llvm.org/D56058

llvm-svn: 351000
2019-01-12 11:12:04 +00:00
Simon Atanasyan 4553cdafe1 [ORC] Rename register in the OrcMips64 resolver code comments. NFC
The `fp` and `s8` register names are synonyms. But `fp` better reflects
a purpose of the register.

llvm-svn: 350023
2018-12-23 12:05:04 +00:00
Simon Atanasyan 15b68b87d5 [ORC] clang-format OrcMips32 and OrcMips64 code. NFC
llvm-svn: 350022
2018-12-23 12:05:00 +00:00
Simon Atanasyan da29981707 [ORC] Remove redundant instruction from MIPS resolver code. NFC
It's redundant to restore the `$a3` register twice.

llvm-svn: 350021
2018-12-23 12:04:55 +00:00
Lang Hames eca6d4b638 [ExecutionEngine] Change NotifyObjectEmitted/NotifyObjectFreed API.
This patch renames both methods (NotifyObjectEmitted -> notifyObjectLoaded, and
NotifyObjectFreed -> notifyObjectFreed), adds an abstract "ObjectKey" (uint64_t)
parameter to notifyObjectLoaded, and replaces the ObjectFile parameter for
notifyObjectFreed with an ObjectKey. Using an ObjectKey to track identify
events, rather than a reference to the ObjectFile, allows us to free the
ObjectFile after notifyObjectLoaded is called, saving memory.

https://reviews.llvm.org/D53773

llvm-svn: 348223
2018-12-04 00:55:15 +00:00
Lang Hames 575515fddf [BuildingAJIT] Update chapter 2 to use the ORCv2 APIs.
llvm-svn: 346726
2018-11-13 01:25:34 +00:00
Lang Hames 91449355f5 [ORC] Fix hex printing of uint64_t values.
A plain "%x" format string will drop the high 32-bits. Use the PRIx64 macro
instead.

llvm-svn: 345696
2018-10-31 05:16:14 +00:00
Matthias Braun 9fd397b423 ADT/STLExtras: Introduce llvm::empty; NFC
This is modeled after C++17 std::empty().

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

llvm-svn: 345679
2018-10-31 00:23:23 +00:00
Lang Hames 23cb2e7f77 [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.
llvm-svn: 345098
2018-10-23 23:01:39 +00:00
Reid Kleckner db367e952e Revert r345077 "[ORC] Change how non-exported symbols are matched during lookup."
Doesn't build on Windows. The call to 'lookup' is ambiguous. Clang and
MSVC agree, anyway.

http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/787
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): error C2668: 'llvm::orc::ExecutionSession::lookup': ambiguous call to overloaded function
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(823): note: could be 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib *>,llvm::orc::SymbolStringPtr)'
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(817): note: or       'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(const llvm::orc::JITDylibSearchList &,llvm::orc::SymbolStringPtr)'
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): note: while trying to match the argument list '(initializer list, llvm::orc::SymbolStringPtr)'

llvm-svn: 345078
2018-10-23 20:54:43 +00:00
Lang Hames 841796decd [ORC] Change how non-exported symbols are matched during lookup.
In the new scheme the client passes a list of (JITDylib&, bool) pairs, rather
than a list of JITDylibs. For each JITDylib the boolean indicates whether or not
to match against non-exported symbols (true means that they should be found,
false means that they should not). The MatchNonExportedInJD and MatchNonExported
parameters on lookup are removed.

The new scheme is more flexible, and easier to understand.

This patch also updates JITDylib search orders to be lists of (JITDylib&, bool)
pairs to match the new lookup scheme. Error handling is also plumbed through
the LLJIT class to allow regression tests to fail predictably when a lookup from
a lazy call-through fails.

llvm-svn: 345077
2018-10-23 20:20:22 +00:00
Lang Hames 3d16af69cf [ORC] Show JITDylib search order in JITDylib::dump.
This can be helpful in debugging search-order related failures.

llvm-svn: 344994
2018-10-23 01:36:32 +00:00
Lang Hames 1aa3292a43 [ORC] Dump flags for JITDylib symbol table entries.
This can help when debugging flag-specific symbol table issues.

llvm-svn: 344993
2018-10-23 01:36:31 +00:00
Lang Hames 95abadec0b [ORC] Guard access to the MemMgrs vector in RTDyldObjectLinkingLayer.
Otherwise we can end up with a data-race when linking concurrently.

This should fix an intermittent failure in the multiple-compile-threads-basic.ll
testcase.

llvm-svn: 344956
2018-10-22 21:17:56 +00:00
Lang Hames 8b94274f22 [ORC] Make the VModuleKey optional, propagate it via MaterializationUnit and
MaterializationResponsibility.

VModuleKeys are intended to enable selective removal of modules from a JIT
session, however for a wide variety of use cases selective removal is not
needed and introduces unnecessary overhead. As of this commit, the default
constructed VModuleKey value is reserved as a "do not track" value, and
becomes the default when adding a new module to the JIT.

This commit also changes the propagation of VModuleKeys. They were passed
alongside the MaterializationResponsibity instance in XXLayer::emit methods,
but are now propagated as part of the MaterializationResponsibility instance
itself (and as part of MaterializationUnit when stored in a JITDylib).
Associating VModuleKeys with MaterializationUnits in this way should allow
for a thread-safe module removal mechanism in the future, even when a module
is in the process of being compiled, by having the
MaterializationResponsibility object check in on its VModuleKey's state
before commiting its results to the JITDylib.

llvm-svn: 344643
2018-10-16 20:13:06 +00:00
Lang Hames 079df9ab2c [ORC] Rename ORC layers to make the "new" ORC layers the default.
This commit adds a 'Legacy' prefix to old ORC layers and utilities, and removes
the '2' suffix from the new ORC layers. If you wish to continue using the old
ORC layers you will need to add a 'Legacy' prefix to your classes. If you were
already using the new ORC layers you will need to drop the '2' suffix.

The legacy layers will remain in-tree until the new layers reach feature
parity with them. This will involve adding support for removing code from the
new layers, and ensuring that performance is comperable.

llvm-svn: 344572
2018-10-15 22:56:10 +00:00
Lang Hames 9f342d9038 [ORC] Rename MultiThreadedSimpleCompiler to ConcurrentIRCompiler.
The new name is a better fit: This class does not actually spawn any new
threads for compilation, it is just safe to call from multiple threads
concurrently.

The "Simple" part of the name did not convey much either, so it was
dropped.

llvm-svn: 344567
2018-10-15 22:36:22 +00:00
Lang Hames 6e66b2a6a3 [ORC] Switch to DenseMap/DenseSet for ORC symbol map/set types.
llvm-svn: 344565
2018-10-15 22:27:02 +00:00
Lang Hames a5157d6f4b [ORC] Simplify naming for JITDylib definition generators.
Renames:
  JITDylib's setFallbackDefinitionGenerator method to setGenerator.
  DynamicLibraryFallbackGenerator class to DynamicLibrarySearchGenerator.
  ReexportsFallbackDefinitionGenerator to ReexportsGenerator.

llvm-svn: 344489
2018-10-15 05:07:54 +00:00
Lang Hames 7899ccbcca [ORC] During lookup, do not match against hidden symbols in other JITDylibs.
This adds two arguments to the main ExecutionSession::lookup method:
MatchNonExportedInJD, and MatchNonExported. These control whether and where
hidden symbols should be matched when searching a list of JITDylibs.

A similar effect could have been achieved by filtering search results, but
this would have involved materializing symbol definitions (since materialization
is triggered on lookup) only to throw the results away, among other issues.

llvm-svn: 344467
2018-10-13 21:53:40 +00:00
Lang Hames bf6603e918 [ORC] Promote and rename private symbols inside the CompileOnDemand layer,
rather than require them to have been promoted before being passed in.

Dropping this precondition is better for layer composition (CompileOnDemandLayer
was the only one that placed pre-conditions on the modules that could be added).
It also means that the promoted private symbols do not show up in the target
JITDylib's symbol table. Instead, they are confined to the hidden implementation
dylib that contains the actual definitions.

For the 403.gcc testcase this cut down the public symbol table size from ~15,000
symbols to ~4000, substantially reducing symbol dependence tracking costs.

llvm-svn: 344078
2018-10-09 20:44:32 +00:00
Lang Hames 535448e08d [ORC] Add a 'remove' method to JITDylib to remove symbols.
Symbols can be removed provided that all are present in the JITDylib and none
are currently in the materializing state. On success all requested symbols are
removed. On failure an error is returned and no symbols are removed.

llvm-svn: 343928
2018-10-06 23:03:59 +00:00
Lang Hames cb5702c3fd [ORC] Pass symbol name to discard by const reference.
This saves some unnecessary atomic ref-counting operations.

llvm-svn: 343927
2018-10-06 23:02:06 +00:00
Lang Hames deb3640d95 [ORC] Pass Symbols to ExecutionSession::lookup by value, potentially saving a
copy.

llvm-svn: 343442
2018-10-01 04:59:10 +00:00
Lang Hames 47d0a37704 [ORC] Add convenience methods for creating DynamicLibraryFallbackGenerators for
libraries on disk, and for the current process.

Avoids more boilerplate during JIT construction.

llvm-svn: 343430
2018-10-01 00:59:28 +00:00
Lang Hames 71d781c434 [ORC] Add an 'intern' method to ExecutionEngine for interning symbol names.
This cuts down on boilerplate by reducing 'ES.getSymbolStringPool().intern(...)'
to 'ES.intern(...)'.

llvm-svn: 343427
2018-09-30 23:18:24 +00:00
Lang Hames d435ce4343 [ORC] Extract and tidy up JITTargetMachineBuilder, add unit test.
(1) Adds comments for the API.

(2) Removes the setArch method: This is redundant: the setArchStr method on the
    triple should be used instead.

(3) Turns EmulatedTLS on by default. This matches EngineBuilder's behavior.

llvm-svn: 343423
2018-09-30 19:12:23 +00:00
Lang Hames 98440293fb [ORC] Add partitioning support to CompileOnDemandLayer2.
CompileOnDemandLayer2 now supports user-supplied partition functions (the
original CompileOnDemandLayer already supported these).

Partition functions are called with the list of requested global values
(i.e. global values that currently have queries waiting on them) and have an
opportunity to select extra global values to materialize at the same time.

Also adds testing infrastructure for the new feature to lli.

llvm-svn: 343396
2018-09-29 23:49:57 +00:00
Lang Hames c3053e41bf [ORC] Clear SymbolToDefinitionMap when materializing a MaterializationUnit.
The map is inaccessible at this point, so we may as well reclaim the memory
early.

llvm-svn: 343395
2018-09-29 23:49:56 +00:00
Lang Hames 2afc22ed9e [ORC] Make MaterializationResponsibility::getRequestedSymbols() const.
This makes it available for use in IRTransformLayer2::TransformFunction
instances (since a const MaterializationResponsibility& parameter was
added in r343365).

llvm-svn: 343367
2018-09-28 22:03:17 +00:00
Lang Hames 3e709d5f78 [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
2018-09-28 21:49:53 +00:00
Lang Hames b62f73420b [ORC] Narrow a cast: the block guarded by the condition only handles
GlobalVariables, not all GlobalValues.

llvm-svn: 343358
2018-09-28 20:16:16 +00:00
Lang Hames 604769943a [ORC] Remove some dead code.
llvm-svn: 343327
2018-09-28 15:13:41 +00:00
Lang Hames 46f40a7128 [ORC] Improve debugging output for ORC.
(1) Print debugging output under a session lock to avoid garbled messages when
compiling on multiple threads.

(2) Name MaterializationUnits, add an ostream operator for them, and so they can
be easily referenced in debugging output, and have that ostream operator
optionally print code/data/hidden symbols provided by that materialization unit
based on command line options.

llvm-svn: 343323
2018-09-28 15:03:11 +00:00
Lang Hames 4328ea3443 [ORC] clang-format the ThreadSafeModule code.
Evidently I forgot to do this before committing r343055.

llvm-svn: 343288
2018-09-28 01:41:33 +00:00
Lang Hames 8b81395db9 [ORC] Add definition for IRLayer::setCloneToNewContextOnEmit, use it to set the
flag to true in LLJIT when running in multithreaded mode.

The IRLayer::setCloneToNewContextOnEmit method sets a flag within the IRLayer
that causes modules added to that layer to be moved to a new context (by
serializing to/from a memory buffer) when they are emitted. This allows modules
that were all loaded on the same context to be compiled in parallel.

llvm-svn: 343266
2018-09-27 21:13:07 +00:00
Lang Hames c5192f751a [ORC] Coalesce all of ORC's symbol renaming / linkage-promotion utilities into
one SymbolLinkagePromoter utility.

SymbolLinkagePromoter renames anonymous and private symbols, and bumps all
linkages to at least global/hidden-visibility. Modules whose symbols have been
promoted by this utility can be decomposed into sub-modules without introducing
link errors. This is used by the CompileOnDemandLayer to extract single-function
modules for lazy compilation.

llvm-svn: 343257
2018-09-27 19:27:20 +00:00
Lang Hames b57c9c4a6e [ORC] Use ExecutionSession's pre-constructed main JITDylib in LLJIT.
As of r342086 ExecutionSession automatically creates a 'main' JITDylib, so
there is no need for LLJIT to create its own.

llvm-svn: 343167
2018-09-27 04:19:32 +00:00
Lang Hames f0a3fd885d Reapply r343058 with a fix for -DLLVM_ENABLE_THREADS=OFF.
Modifies lit to add a 'thread_support' feature that can be used in lit test
REQUIRES clauses. The thread_support flag is set if -DLLVM_ENABLE_THREADS=ON
and unset if -DLLVM_ENABLE_THREADS=OFF. The lit flag is used to disable the
multiple-compile-threads-basic.ll testcase when threading is disabled.

llvm-svn: 343122
2018-09-26 16:26:59 +00:00
Hans Wennborg 20b5abe23b Revert r343058 "[ORC] Add support for multithreaded compiles to LLJIT and LLLazyJIT."
This doesn't work well in builds configured with LLVM_ENABLE_THREADS=OFF,
causing the following assert when running
ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll:

  lib/ExecutionEngine/Orc/Core.cpp:1748: Expected<llvm::JITEvaluatedSymbol>
  llvm::orc::lookup(const llvm::orc::JITDylibList &, llvm::orc::SymbolStringPtr):
  Assertion `ResultMap->size() == 1 && "Unexpected number of results"' failed.

> LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads
> arguments. If this is non-zero then a thread-pool will be created with the
> given number of threads, and compile tasks will be dispatched to the thread
> pool.
>
> To enable testing of this feature, two new flags are added to lli:
>
> (1) -compile-threads=N (N = 0 by default) controls the number of compile threads
> to use.
>
> (2) -thread-entry can be used to execute code on additional threads. For each
> -thread-entry argument supplied (multiple are allowed) a new thread will be
> created and the given symbol called. These additional thread entry points are
> called after static constructors are run, but before main.

llvm-svn: 343099
2018-09-26 12:15:23 +00:00
Lang Hames d8048675f4 [ORC] Update CompileOnDemandLayer2 to use the new lazyReexports mechanism
for lazy compilation, rather than a callback manager.

The new mechanism does not block compile threads, and does not require
function bodies to be renamed.

Future modifications should allow laziness on a per-module basis to work
without any modification of the input module.

llvm-svn: 343065
2018-09-26 05:08:29 +00:00
Lang Hames c1275e72cb [ORC] Add a "lazy call-through" utility based on the same underlying trampoline
implementation as lazy compile callbacks, and a "lazy re-exports" utility that
builds lazy call-throughs.

Lazy call-throughs are similar to lazy compile callbacks (and are based on the
same underlying state saving/restoring trampolines) but resolve their targets
by performing a standard ORC lookup rather than invoking a user supplied
compiler callback. This allows them to inherit the thread-safety of ORC lookups
while blocking only the calling thread (whereas compile callbacks also block one
compile thread).

Lazy re-exports provide a simple way of building lazy call-throughs. Unlike a
regular re-export, a lazy re-export generates a new address (a stub entry point)
that will act like the re-exported symbol when called. The first call via a
lazy re-export will trigger compilation of the re-exported symbol before calling
through to it.

llvm-svn: 343061
2018-09-26 04:18:30 +00:00
Lang Hames 50b3344148 [ORC] Refactor trampoline pool management out of JITCompileCallbackManager.
This will allow trampoline pools to be re-used for a new lazy-reexport utility
that generates looks up function bodies using the standard symbol lookup process
(rather than using a user provided compile function). This new utility provides
the same capabilities (since MaterializationUnits already allow user supplied
compile functions to be run) as JITCompileCallbackManager, but can use the new
asynchronous lookup functions to avoid blocking a compile thread.

This patch also updates createLocalCompileCallbackManager to return an error if
a callback manager can not be created, and updates clients of that API to
account for the change. Finally, the OrcCBindingsStack is updates so that if
a callback manager is not available for the target platform a valid stack
(without support for lazy compilation) can still be constructed.

llvm-svn: 343059
2018-09-26 03:32:12 +00:00
Lang Hames 225a32af72 [ORC] Add support for multithreaded compiles to LLJIT and LLLazyJIT.
LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads
arguments. If this is non-zero then a thread-pool will be created with the
given number of threads, and compile tasks will be dispatched to the thread
pool.

To enable testing of this feature, two new flags are added to lli:

(1) -compile-threads=N (N = 0 by default) controls the number of compile threads
to use.

(2) -thread-entry can be used to execute code on additional threads. For each
-thread-entry argument supplied (multiple are allowed) a new thread will be
created and the given symbol called. These additional thread entry points are
called after static constructors are run, but before main.

llvm-svn: 343058
2018-09-26 02:39:42 +00:00
Lang Hames 8d76c71154 [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
2018-09-26 01:24:12 +00:00
Lang Hames abeedf1812 [ORC] Add an asynchronous jit-link function, jitLinkForORC, to RuntimeDyld and
switch RTDyldObjectLinkingLayer2 to use it.

RuntimeDyld::loadObject is currently a blocking operation. This means that any
JIT'd code whose call-graph contains an embedded complete K graph will require
at least K threads to link, which precludes the use of a fixed sized thread
pool for concurrent JITing of arbitrary code (whatever K the thread-pool is set
at, any code with a K+1 complete subgraph will deadlock at JIT-link time).

To address this issue, this commmit introduces a function called jitLinkForORC
that uses continuation-passing style to pass the fix-up and finalization steps
to the asynchronous symbol resolver interface so that linking can be performed
without blocking.

llvm-svn: 343043
2018-09-25 22:57:44 +00:00
Lang Hames adde5ba4b2 [ORC] Reapply r342939 with a fix for MSVC's promise/future restrictions.
llvm-svn: 343012
2018-09-25 19:48:46 +00:00
Lang Hames 99bfa95ae3 Revert "[ORC] Switch to asynchronous resolution in JITSymbolResolver."
This reverts commit r342939.

MSVC's promise/future implementation does not like types that are not default
constructible. Reverting while I figure out a solution.

llvm-svn: 342941
2018-09-25 04:54:03 +00:00