[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
//===-- IndirectionUtils.h - Utilities for adding indirections --*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Contains utilities for adding indirections and breaking up modules.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_EXECUTIONENGINE_ORC_INDIRECTIONUTILS_H
|
|
|
|
#define LLVM_EXECUTIONENGINE_ORC_INDIRECTIONUTILS_H
|
|
|
|
|
2015-02-09 01:20:51 +00:00
|
|
|
#include "JITSymbol.h"
|
2015-04-29 01:33:35 +00:00
|
|
|
#include "LambdaResolver.h"
|
2015-02-17 01:18:38 +00:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
#include "llvm/ExecutionEngine/RuntimeDyld.h"
|
2015-02-17 01:18:38 +00:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
#include "llvm/IR/Mangler.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2015-05-05 17:37:18 +00:00
|
|
|
#include "llvm/Transforms/Utils/ValueMapper.h"
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
#include <sstream>
|
|
|
|
|
|
|
|
namespace llvm {
|
2015-02-21 20:44:36 +00:00
|
|
|
namespace orc {
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
/// @brief Base class for JITLayer independent aspects of
|
|
|
|
/// JITCompileCallbackManager.
|
|
|
|
class JITCompileCallbackManagerBase {
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
public:
|
|
|
|
|
2015-03-25 02:45:50 +00:00
|
|
|
typedef std::function<TargetAddress()> CompileFtor;
|
|
|
|
|
|
|
|
/// @brief Handle to a newly created compile callback. Can be used to get an
|
|
|
|
/// IR constant representing the address of the trampoline, and to set
|
2015-05-05 17:37:18 +00:00
|
|
|
/// the compile action for the callback.
|
2015-03-25 02:45:50 +00:00
|
|
|
class CompileCallbackInfo {
|
|
|
|
public:
|
2015-05-05 17:37:18 +00:00
|
|
|
CompileCallbackInfo(TargetAddress Addr, CompileFtor &Compile)
|
|
|
|
: Addr(Addr), Compile(Compile) {}
|
2015-03-25 02:45:50 +00:00
|
|
|
|
2015-03-29 21:55:27 +00:00
|
|
|
TargetAddress getAddress() const { return Addr; }
|
2015-03-25 02:45:50 +00:00
|
|
|
void setCompileAction(CompileFtor Compile) {
|
|
|
|
this->Compile = std::move(Compile);
|
|
|
|
}
|
|
|
|
private:
|
2015-03-29 21:55:27 +00:00
|
|
|
TargetAddress Addr;
|
2015-03-25 02:45:50 +00:00
|
|
|
CompileFtor &Compile;
|
|
|
|
};
|
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
/// @brief Construct a JITCompileCallbackManagerBase.
|
|
|
|
/// @param ErrorHandlerAddress The address of an error handler in the target
|
|
|
|
/// process to be used if a compile callback fails.
|
|
|
|
/// @param NumTrampolinesPerBlock Number of trampolines to emit if there is no
|
|
|
|
/// available trampoline when getCompileCallback is
|
|
|
|
/// called.
|
|
|
|
JITCompileCallbackManagerBase(TargetAddress ErrorHandlerAddress,
|
|
|
|
unsigned NumTrampolinesPerBlock)
|
|
|
|
: ErrorHandlerAddress(ErrorHandlerAddress),
|
|
|
|
NumTrampolinesPerBlock(NumTrampolinesPerBlock) {}
|
|
|
|
|
2015-03-25 02:45:50 +00:00
|
|
|
virtual ~JITCompileCallbackManagerBase() {}
|
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
/// @brief Execute the callback for the given trampoline id. Called by the JIT
|
|
|
|
/// to compile functions on demand.
|
2015-05-05 17:37:18 +00:00
|
|
|
TargetAddress executeCompileCallback(TargetAddress TrampolineAddr) {
|
|
|
|
auto I = ActiveTrampolines.find(TrampolineAddr);
|
2015-02-17 01:18:38 +00:00
|
|
|
// FIXME: Also raise an error in the Orc error-handler when we finally have
|
|
|
|
// one.
|
|
|
|
if (I == ActiveTrampolines.end())
|
|
|
|
return ErrorHandlerAddress;
|
|
|
|
|
|
|
|
// Found a callback handler. Yank this trampoline out of the active list and
|
|
|
|
// put it back in the available trampolines list, then try to run the
|
|
|
|
// handler's compile and update actions.
|
|
|
|
// Moving the trampoline ID back to the available list first means there's at
|
|
|
|
// least one available trampoline if the compile action triggers a request for
|
|
|
|
// a new one.
|
2015-05-05 17:37:18 +00:00
|
|
|
auto Compile = std::move(I->second);
|
2015-02-17 01:18:38 +00:00
|
|
|
ActiveTrampolines.erase(I);
|
2015-05-05 17:37:18 +00:00
|
|
|
AvailableTrampolines.push_back(TrampolineAddr);
|
2015-02-17 01:18:38 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
if (auto Addr = Compile())
|
2015-02-17 01:18:38 +00:00
|
|
|
return Addr;
|
2015-05-05 17:37:18 +00:00
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
return ErrorHandlerAddress;
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
}
|
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
/// @brief Reserve a compile callback.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
virtual CompileCallbackInfo getCompileCallback(LLVMContext &Context) = 0;
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
/// @brief Get a CompileCallbackInfo for an existing callback.
|
|
|
|
CompileCallbackInfo getCompileCallbackInfo(TargetAddress TrampolineAddr) {
|
|
|
|
auto I = ActiveTrampolines.find(TrampolineAddr);
|
|
|
|
assert(I != ActiveTrampolines.end() && "Not an active trampoline.");
|
|
|
|
return CompileCallbackInfo(I->first, I->second);
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
/// @brief Release a compile callback.
|
|
|
|
///
|
|
|
|
/// Note: Callbacks are auto-released after they execute. This method should
|
|
|
|
/// only be called to manually release a callback that is not going to
|
|
|
|
/// execute.
|
|
|
|
void releaseCompileCallback(TargetAddress TrampolineAddr) {
|
|
|
|
auto I = ActiveTrampolines.find(TrampolineAddr);
|
|
|
|
assert(I != ActiveTrampolines.end() && "Not an active trampoline.");
|
|
|
|
ActiveTrampolines.erase(I);
|
|
|
|
AvailableTrampolines.push_back(TrampolineAddr);
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
protected:
|
2015-02-17 01:18:38 +00:00
|
|
|
TargetAddress ErrorHandlerAddress;
|
|
|
|
unsigned NumTrampolinesPerBlock;
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
typedef std::map<TargetAddress, CompileFtor> TrampolineMapT;
|
2015-02-17 01:18:38 +00:00
|
|
|
TrampolineMapT ActiveTrampolines;
|
|
|
|
std::vector<TargetAddress> AvailableTrampolines;
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
};
|
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
/// @brief Manage compile callbacks.
|
|
|
|
template <typename JITLayerT, typename TargetT>
|
2015-03-25 02:45:50 +00:00
|
|
|
class JITCompileCallbackManager : public JITCompileCallbackManagerBase {
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
public:
|
2015-02-17 01:18:38 +00:00
|
|
|
|
|
|
|
/// @brief Construct a JITCompileCallbackManager.
|
|
|
|
/// @param JIT JIT layer to emit callback trampolines, etc. into.
|
|
|
|
/// @param Context LLVMContext to use for trampoline & resolve block modules.
|
|
|
|
/// @param ErrorHandlerAddress The address of an error handler in the target
|
|
|
|
/// process to be used if a compile callback fails.
|
|
|
|
/// @param NumTrampolinesPerBlock Number of trampolines to allocate whenever
|
|
|
|
/// there is no existing callback trampoline.
|
|
|
|
/// (Trampolines are allocated in blocks for
|
|
|
|
/// efficiency.)
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
JITCompileCallbackManager(JITLayerT &JIT, RuntimeDyld::MemoryManager &MemMgr,
|
|
|
|
LLVMContext &Context,
|
2015-02-17 01:18:38 +00:00
|
|
|
TargetAddress ErrorHandlerAddress,
|
|
|
|
unsigned NumTrampolinesPerBlock)
|
2015-03-25 02:45:50 +00:00
|
|
|
: JITCompileCallbackManagerBase(ErrorHandlerAddress,
|
|
|
|
NumTrampolinesPerBlock),
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
JIT(JIT), MemMgr(MemMgr) {
|
2015-02-17 01:18:38 +00:00
|
|
|
emitResolverBlock(Context);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// @brief Get/create a compile callback with the given signature.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
CompileCallbackInfo getCompileCallback(LLVMContext &Context) final {
|
|
|
|
TargetAddress TrampolineAddr = getAvailableTrampolineAddr(Context);
|
2015-05-05 17:37:18 +00:00
|
|
|
auto &Compile = this->ActiveTrampolines[TrampolineAddr];
|
|
|
|
return CompileCallbackInfo(TrampolineAddr, Compile);
|
2015-02-17 01:18:38 +00:00
|
|
|
}
|
|
|
|
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
private:
|
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
std::vector<std::unique_ptr<Module>>
|
|
|
|
SingletonSet(std::unique_ptr<Module> M) {
|
|
|
|
std::vector<std::unique_ptr<Module>> Ms;
|
|
|
|
Ms.push_back(std::move(M));
|
|
|
|
return Ms;
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
void emitResolverBlock(LLVMContext &Context) {
|
|
|
|
std::unique_ptr<Module> M(new Module("resolver_block_module",
|
|
|
|
Context));
|
|
|
|
TargetT::insertResolverBlock(*M, *this);
|
2015-04-29 01:33:35 +00:00
|
|
|
auto NonResolver =
|
|
|
|
createLambdaResolver(
|
|
|
|
[](const std::string &Name) -> RuntimeDyld::SymbolInfo {
|
|
|
|
llvm_unreachable("External symbols in resolver block?");
|
|
|
|
},
|
|
|
|
[](const std::string &Name) -> RuntimeDyld::SymbolInfo {
|
|
|
|
llvm_unreachable("Dylib symbols in resolver block?");
|
|
|
|
});
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
auto H = JIT.addModuleSet(SingletonSet(std::move(M)), &MemMgr,
|
2015-04-29 01:33:35 +00:00
|
|
|
std::move(NonResolver));
|
2015-02-17 01:18:38 +00:00
|
|
|
JIT.emitAndFinalize(H);
|
|
|
|
auto ResolverBlockSymbol =
|
|
|
|
JIT.findSymbolIn(H, TargetT::ResolverBlockName, false);
|
|
|
|
assert(ResolverBlockSymbol && "Failed to insert resolver block");
|
|
|
|
ResolverBlockAddr = ResolverBlockSymbol.getAddress();
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
TargetAddress getAvailableTrampolineAddr(LLVMContext &Context) {
|
|
|
|
if (this->AvailableTrampolines.empty())
|
|
|
|
grow(Context);
|
|
|
|
assert(!this->AvailableTrampolines.empty() &&
|
|
|
|
"Failed to grow available trampolines.");
|
|
|
|
TargetAddress TrampolineAddr = this->AvailableTrampolines.back();
|
|
|
|
this->AvailableTrampolines.pop_back();
|
|
|
|
return TrampolineAddr;
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
void grow(LLVMContext &Context) {
|
|
|
|
assert(this->AvailableTrampolines.empty() && "Growing prematurely?");
|
|
|
|
std::unique_ptr<Module> M(new Module("trampoline_block", Context));
|
|
|
|
auto GetLabelName =
|
|
|
|
TargetT::insertCompileCallbackTrampolines(*M, ResolverBlockAddr,
|
|
|
|
this->NumTrampolinesPerBlock,
|
|
|
|
this->ActiveTrampolines.size());
|
2015-04-29 01:33:35 +00:00
|
|
|
auto NonResolver =
|
|
|
|
createLambdaResolver(
|
|
|
|
[](const std::string &Name) -> RuntimeDyld::SymbolInfo {
|
|
|
|
llvm_unreachable("External symbols in trampoline block?");
|
|
|
|
},
|
|
|
|
[](const std::string &Name) -> RuntimeDyld::SymbolInfo {
|
|
|
|
llvm_unreachable("Dylib symbols in trampoline block?");
|
|
|
|
});
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
auto H = JIT.addModuleSet(SingletonSet(std::move(M)), &MemMgr,
|
2015-04-29 01:33:35 +00:00
|
|
|
std::move(NonResolver));
|
2015-02-17 01:18:38 +00:00
|
|
|
JIT.emitAndFinalize(H);
|
|
|
|
for (unsigned I = 0; I < this->NumTrampolinesPerBlock; ++I) {
|
|
|
|
std::string Name = GetLabelName(I);
|
|
|
|
auto TrampolineSymbol = JIT.findSymbolIn(H, Name, false);
|
|
|
|
assert(TrampolineSymbol && "Failed to emit trampoline.");
|
|
|
|
this->AvailableTrampolines.push_back(TrampolineSymbol.getAddress());
|
|
|
|
}
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
}
|
|
|
|
|
2015-02-17 01:18:38 +00:00
|
|
|
JITLayerT &JIT;
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
RuntimeDyld::MemoryManager &MemMgr;
|
2015-02-17 01:18:38 +00:00
|
|
|
TargetAddress ResolverBlockAddr;
|
|
|
|
};
|
|
|
|
|
2015-04-11 00:23:49 +00:00
|
|
|
/// @brief Build a function pointer of FunctionType with the given constant
|
|
|
|
/// address.
|
|
|
|
///
|
|
|
|
/// Usage example: Turn a trampoline address into a function pointer constant
|
|
|
|
/// for use in a stub.
|
|
|
|
Constant* createIRTypedAddress(FunctionType &FT, TargetAddress Addr);
|
2015-02-17 01:18:38 +00:00
|
|
|
|
2015-04-11 00:23:49 +00:00
|
|
|
/// @brief Create a function pointer with the given type, name, and initializer
|
|
|
|
/// in the given Module.
|
|
|
|
GlobalVariable* createImplPointer(PointerType &PT, Module &M,
|
|
|
|
const Twine &Name, Constant *Initializer);
|
|
|
|
|
|
|
|
/// @brief Turn a function declaration into a stub function that makes an
|
|
|
|
/// indirect call using the given function pointer.
|
2015-02-17 01:18:38 +00:00
|
|
|
void makeStub(Function &F, GlobalVariable &ImplPointer);
|
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
/// @brief Raise linkage types and rename as necessary to ensure that all
|
|
|
|
/// symbols are accessible for other modules.
|
|
|
|
///
|
|
|
|
/// This should be called before partitioning a module to ensure that the
|
|
|
|
/// partitions retain access to each other's symbols.
|
|
|
|
void makeAllSymbolsExternallyAccessible(Module &M);
|
2015-05-04 23:30:01 +00:00
|
|
|
|
2015-05-05 17:37:18 +00:00
|
|
|
/// @brief Clone a function declaration into a new module.
|
|
|
|
///
|
|
|
|
/// This function can be used as the first step towards creating a callback
|
|
|
|
/// stub (see makeStub), or moving a function body (see moveFunctionBody).
|
|
|
|
///
|
|
|
|
/// If the VMap argument is non-null, a mapping will be added between F and
|
|
|
|
/// the new declaration, and between each of F's arguments and the new
|
|
|
|
/// declaration's arguments. This map can then be passed in to moveFunction to
|
|
|
|
/// move the function body if required. Note: When moving functions between
|
|
|
|
/// modules with these utilities, all decls should be cloned (and added to a
|
|
|
|
/// single VMap) before any bodies are moved. This will ensure that references
|
|
|
|
/// between functions all refer to the versions in the new module.
|
|
|
|
Function* cloneFunctionDecl(Module &Dst, const Function &F,
|
|
|
|
ValueToValueMapTy *VMap = nullptr);
|
|
|
|
|
|
|
|
/// @brief Move the body of function 'F' to a cloned function declaration in a
|
|
|
|
/// different module (See related cloneFunctionDecl).
|
|
|
|
///
|
|
|
|
/// If the target function declaration is not supplied via the NewF parameter
|
|
|
|
/// then it will be looked up via the VMap.
|
|
|
|
///
|
|
|
|
/// This will delete the body of function 'F' from its original parent module,
|
|
|
|
/// but leave its declaration.
|
|
|
|
void moveFunctionBody(Function &OrigF, ValueToValueMapTy &VMap,
|
|
|
|
ValueMaterializer *Materializer = nullptr,
|
|
|
|
Function *NewF = nullptr);
|
|
|
|
|
|
|
|
/// @brief Clone a global variable declaration into a new module.
|
|
|
|
GlobalVariable* cloneGlobalVariableDecl(Module &Dst, const GlobalVariable &GV,
|
|
|
|
ValueToValueMapTy *VMap = nullptr);
|
|
|
|
|
|
|
|
/// @brief Move global variable GV from its parent module to cloned global
|
|
|
|
/// declaration in a different module.
|
|
|
|
///
|
|
|
|
/// If the target global declaration is not supplied via the NewGV parameter
|
|
|
|
/// then it will be looked up via the VMap.
|
|
|
|
///
|
|
|
|
/// This will delete the initializer of GV from its original parent module,
|
|
|
|
/// but leave its declaration.
|
|
|
|
void moveGlobalVariableInitializer(GlobalVariable &OrigGV,
|
|
|
|
ValueToValueMapTy &VMap,
|
|
|
|
ValueMaterializer *Materializer = nullptr,
|
|
|
|
GlobalVariable *NewGV = nullptr);
|
2015-02-17 01:18:38 +00:00
|
|
|
|
2015-02-21 20:44:36 +00:00
|
|
|
} // End namespace orc.
|
|
|
|
} // End namespace llvm.
|
[Orc] New JIT APIs.
This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
cleanly support a wider range of JIT use cases in LLVM, and encourage the
development and contribution of re-usable infrastructure for LLVM JIT use-cases.
These APIs are intended to live alongside the MCJIT APIs, and should not affect
existing clients.
Included in this patch:
1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
components for building JIT infrastructure.
Implementation code for these headers lives in lib/ExecutionEngine/Orc.
2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
new components.
3) Minor changes to RTDyldMemoryManager needed to support the new components.
These changes should not impact existing clients.
4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
OrcMCJITReplacement class as its underlying execution engine, rather than
MCJIT itself.
Tests to follow shortly.
Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
|
|
|
|
|
|
|
#endif // LLVM_EXECUTIONENGINE_ORC_INDIRECTIONUTILS_H
|