mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-29 13:29:28 +00:00
da62155c11
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
|
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| Makefile | ||
| README.txt | ||
| toy.cpp | ||
//===----------------------------------------------------------------------===/ // Kaleidoscope with Orc - Lazy IRGen Version //===----------------------------------------------------------------------===// This version of Kaleidoscope with Orc demonstrates fully lazy IR-generation. Building on the lazy-irgen version of the tutorial, this version injects JIT callbacks to defer the bulk of IR-generation and code-generation of functions until they are first called. When a function definition is entered, a JIT callback is created and a stub function is built that will call the body of the function indirectly. The body of the function is *not* IRGen'd at this point. Instead, the function pointer for the indirect call is initialized to point at the JIT callback, and the compile action for the callback is initialized with a lambda that IRGens the body of the function and adds it to the JIT. The function pointer is updated by the JIT callback's update action to point at the newly emitted function body, so future calls to the stub will go straight to the body, not through the JIT. This directory contains a Makefile that allows the code to be built in a standalone manner, independent of the larger LLVM build infrastructure. To build the program you will need to have 'clang++' and 'llvm-config' in your path.