mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-05-11 21:56:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm/lib/ExecutionEngine/Orc/OrcABISupport.cpp

542 lines
24 KiB
C++
Raw Normal View History

[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 03:36:38 +00:00
//===------------- OrcABISupport.cpp - ABI specific support code ----------===//
[Orc] Add license header to OrcTargetSupport. llvm-svn: 251274
2015-10-26 06:40:28 +00:00
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 03:36:38 +00:00
#include "llvm/ExecutionEngine/Orc/OrcABISupport.h"
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
#include "llvm/Support/Process.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. llvm-svn: 226940
2015-01-23 21:25:00 +00:00
namespace llvm {
[Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code. NFC. llvm-svn: 230143
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. llvm-svn: 226940
2015-01-23 21:25:00 +00:00
[Orc] Add ORC lazy-compilation support for AArch64. The ORC compile callbacks and indirect stubs APIs will now work for AArc64, allowing functions to be lazily compiled and/or updated. llvm-svn: 268112
2016-04-29 21:32:00 +00:00
void OrcAArch64::writeResolverCode(uint8_t *ResolverMem, JITReentryFn ReentryFn,
void *CallbackMgr) {
const uint32_t ResolverCode[] = {
// resolver_entry:
[ORC] Save AArch64 NEON state in the JIT reentry block. The earlier version of the resolver code did not save NEON state, so it would have broken any callees that used floating point. llvm-svn: 268173
2016-05-01 00:14:45 +00:00
0xa9bf47fd, // 0x000: stp x29, x17, [sp, #-16]!
0x910003fd, // 0x004: mov x29, sp
0xa9bf73fb, // 0x008: stp x27, x28, [sp, #-16]!
0xa9bf6bf9, // 0x00c: stp x25, x26, [sp, #-16]!
0xa9bf63f7, // 0x010: stp x23, x24, [sp, #-16]!
0xa9bf5bf5, // 0x014: stp x21, x22, [sp, #-16]!
0xa9bf53f3, // 0x018: stp x19, x20, [sp, #-16]!
0xa9bf3fee, // 0x01c: stp x14, x15, [sp, #-16]!
0xa9bf37ec, // 0x020: stp x12, x13, [sp, #-16]!
0xa9bf2fea, // 0x024: stp x10, x11, [sp, #-16]!
0xa9bf27e8, // 0x028: stp x8, x9, [sp, #-16]!
0xa9bf1fe6, // 0x02c: stp x6, x7, [sp, #-16]!
0xa9bf17e4, // 0x030: stp x4, x5, [sp, #-16]!
0xa9bf0fe2, // 0x034: stp x2, x3, [sp, #-16]!
0xa9bf07e0, // 0x038: stp x0, x1, [sp, #-16]!
0xadbf7ffe, // 0x03c: stp q30, q31, [sp, #-32]!
0xadbf77fc, // 0x040: stp q28, q29, [sp, #-32]!
0xadbf6ffa, // 0x044: stp q26, q27, [sp, #-32]!
0xadbf67f8, // 0x048: stp q24, q25, [sp, #-32]!
0xadbf5ff6, // 0x04c: stp q22, q23, [sp, #-32]!
0xadbf57f4, // 0x050: stp q20, q21, [sp, #-32]!
0xadbf4ff2, // 0x054: stp q18, q19, [sp, #-32]!
0xadbf47f0, // 0x058: stp q16, q17, [sp, #-32]!
0xadbf3fee, // 0x05c: stp q14, q15, [sp, #-32]!
0xadbf37ec, // 0x060: stp q12, q13, [sp, #-32]!
0xadbf2fea, // 0x064: stp q10, q11, [sp, #-32]!
0xadbf27e8, // 0x068: stp q8, q9, [sp, #-32]!
0xadbf1fe6, // 0x06c: stp q6, q7, [sp, #-32]!
0xadbf17e4, // 0x070: stp q4, q5, [sp, #-32]!
0xadbf0fe2, // 0x074: stp q2, q3, [sp, #-32]!
0xadbf07e0, // 0x078: stp q0, q1, [sp, #-32]!
0x580004e0, // 0x07c: ldr x0, Lcallbackmgr
0xaa1e03e1, // 0x080: mov x1, x30
0xd1003021, // 0x084: sub x1, x1, #12
0x58000442, // 0x088: ldr x2, Lreentry_fn_ptr
0xd63f0040, // 0x08c: blr x2
0xaa0003f1, // 0x090: mov x17, x0
0xacc107e0, // 0x094: ldp q0, q1, [sp], #32
0xacc10fe2, // 0x098: ldp q2, q3, [sp], #32
0xacc117e4, // 0x09c: ldp q4, q5, [sp], #32
0xacc11fe6, // 0x0a0: ldp q6, q7, [sp], #32
0xacc127e8, // 0x0a4: ldp q8, q9, [sp], #32
0xacc12fea, // 0x0a8: ldp q10, q11, [sp], #32
0xacc137ec, // 0x0ac: ldp q12, q13, [sp], #32
0xacc13fee, // 0x0b0: ldp q14, q15, [sp], #32
0xacc147f0, // 0x0b4: ldp q16, q17, [sp], #32
0xacc14ff2, // 0x0b8: ldp q18, q19, [sp], #32
0xacc157f4, // 0x0bc: ldp q20, q21, [sp], #32
0xacc15ff6, // 0x0c0: ldp q22, q23, [sp], #32
0xacc167f8, // 0x0c4: ldp q24, q25, [sp], #32
0xacc16ffa, // 0x0c8: ldp q26, q27, [sp], #32
0xacc177fc, // 0x0cc: ldp q28, q29, [sp], #32
0xacc17ffe, // 0x0d0: ldp q30, q31, [sp], #32
0xa8c107e0, // 0x0d4: ldp x0, x1, [sp], #16
0xa8c10fe2, // 0x0d8: ldp x2, x3, [sp], #16
0xa8c117e4, // 0x0dc: ldp x4, x5, [sp], #16
0xa8c11fe6, // 0x0e0: ldp x6, x7, [sp], #16
0xa8c127e8, // 0x0e4: ldp x8, x9, [sp], #16
0xa8c12fea, // 0x0e8: ldp x10, x11, [sp], #16
0xa8c137ec, // 0x0ec: ldp x12, x13, [sp], #16
0xa8c13fee, // 0x0f0: ldp x14, x15, [sp], #16
0xa8c153f3, // 0x0f4: ldp x19, x20, [sp], #16
0xa8c15bf5, // 0x0f8: ldp x21, x22, [sp], #16
0xa8c163f7, // 0x0fc: ldp x23, x24, [sp], #16
0xa8c16bf9, // 0x100: ldp x25, x26, [sp], #16
0xa8c173fb, // 0x104: ldp x27, x28, [sp], #16
0xa8c17bfd, // 0x108: ldp x29, x30, [sp], #16
0xd65f0220, // 0x10c: ret x17
0x01234567, // 0x110: Lreentry_fn_ptr:
0xdeadbeef, // 0x114: .quad 0
0x98765432, // 0x118: Lcallbackmgr:
0xcafef00d // 0x11c: .quad 0
[Orc] Add ORC lazy-compilation support for AArch64. The ORC compile callbacks and indirect stubs APIs will now work for AArc64, allowing functions to be lazily compiled and/or updated. llvm-svn: 268112
2016-04-29 21:32:00 +00:00
};
[ORC] Save AArch64 NEON state in the JIT reentry block. The earlier version of the resolver code did not save NEON state, so it would have broken any callees that used floating point. llvm-svn: 268173
2016-05-01 00:14:45 +00:00
const unsigned ReentryFnAddrOffset = 0x110;
const unsigned CallbackMgrAddrOffset = 0x118;
[Orc] Add ORC lazy-compilation support for AArch64. The ORC compile callbacks and indirect stubs APIs will now work for AArc64, allowing functions to be lazily compiled and/or updated. llvm-svn: 268112
2016-04-29 21:32:00 +00:00
memcpy(ResolverMem, ResolverCode, sizeof(ResolverCode));
memcpy(ResolverMem + ReentryFnAddrOffset, &ReentryFn, sizeof(ReentryFn));
memcpy(ResolverMem + CallbackMgrAddrOffset, &CallbackMgr,
sizeof(CallbackMgr));
}
void OrcAArch64::writeTrampolines(uint8_t *TrampolineMem, void *ResolverAddr,
unsigned NumTrampolines) {
unsigned OffsetToPtr = alignTo(NumTrampolines * TrampolineSize, 8);
memcpy(TrampolineMem + OffsetToPtr, &ResolverAddr, sizeof(void *));
// OffsetToPtr is actually the offset from the PC for the 2nd instruction, so
// subtract 32-bits.
OffsetToPtr -= 4;
uint32_t *Trampolines = reinterpret_cast<uint32_t *>(TrampolineMem);
for (unsigned I = 0; I < NumTrampolines; ++I, OffsetToPtr -= TrampolineSize) {
Trampolines[3 * I + 0] = 0xaa1e03f1; // mov x17, x30
[ORC] Fix a typo. llvm-svn: 313346
2017-09-15 06:50:19 +00:00
Trampolines[3 * I + 1] = 0x58000010 | (OffsetToPtr << 3); // adr x16, Lptr
[Orc] Add ORC lazy-compilation support for AArch64. The ORC compile callbacks and indirect stubs APIs will now work for AArc64, allowing functions to be lazily compiled and/or updated. llvm-svn: 268112
2016-04-29 21:32:00 +00:00
Trampolines[3 * I + 2] = 0xd63f0200; // blr x16
}
}
Error OrcAArch64::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
unsigned MinStubs,
void *InitialPtrVal) {
// Stub format is:
//
// .section __orc_stubs
// stub1:
// ldr x0, ptr1 ; PC-rel load of ptr1
// br x0 ; Jump to resolver
// stub2:
// ldr x0, ptr2 ; PC-rel load of ptr2
// br x0 ; Jump to resolver
//
// ...
//
// .section __orc_ptrs
// ptr1:
// .quad 0x0
// ptr2:
// .quad 0x0
//
// ...
const unsigned StubSize = IndirectStubsInfo::StubSize;
// Emit at least MinStubs, rounded up to fill the pages allocated.
unsigned PageSize = sys::Process::getPageSize();
unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
unsigned NumStubs = (NumPages * PageSize) / StubSize;
// Allocate memory for stubs and pointers in one call.
std::error_code EC;
auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
2 * NumPages * PageSize, nullptr,
sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
if (EC)
return errorCodeToError(EC);
// Create separate MemoryBlocks representing the stubs and pointers.
sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
NumPages * PageSize,
NumPages * PageSize);
// Populate the stubs page stubs and mark it executable.
uint64_t *Stub = reinterpret_cast<uint64_t *>(StubsBlock.base());
uint64_t PtrOffsetField = static_cast<uint64_t>(NumPages * PageSize)
<< 3;
for (unsigned I = 0; I < NumStubs; ++I)
Stub[I] = 0xd61f020058000010 | PtrOffsetField;
if (auto EC = sys::Memory::protectMappedMemory(
StubsBlock, sys::Memory::MF_READ | sys::Memory::MF_EXEC))
return errorCodeToError(EC);
// Initialize all pointers to point at FailureAddress.
void **Ptr = reinterpret_cast<void **>(PtrsBlock.base());
for (unsigned I = 0; I < NumStubs; ++I)
Ptr[I] = InitialPtrVal;
StubsInfo = IndirectStubsInfo(NumStubs, std::move(StubsMem));
return Error::success();
}
[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 03:36:38 +00:00
void OrcX86_64_Base::writeTrampolines(uint8_t *TrampolineMem,
void *ResolverAddr,
unsigned NumTrampolines) {
[Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer. This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
2015-02-17 01:18:38 +00:00
Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block and trampolines."" This reverts commit r251937. The test was updated to the new API, bring the API back. llvm-svn: 251944
2015-11-03 16:40:37 +00:00
unsigned OffsetToPtr = NumTrampolines * TrampolineSize;
[Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer. This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
2015-02-17 01:18:38 +00:00
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
memcpy(TrampolineMem + OffsetToPtr, &ResolverAddr, sizeof(void *));
[Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer. This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
2015-02-17 01:18:38 +00:00
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
uint64_t *Trampolines = reinterpret_cast<uint64_t *>(TrampolineMem);
Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block and trampolines."" This reverts commit r251937. The test was updated to the new API, bring the API back. llvm-svn: 251944
2015-11-03 16:40:37 +00:00
uint64_t CallIndirPCRel = 0xf1c40000000015ff;
[Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer. This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
2015-02-17 01:18:38 +00:00
Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block and trampolines."" This reverts commit r251937. The test was updated to the new API, bring the API back. llvm-svn: 251944
2015-11-03 16:40:37 +00:00
for (unsigned I = 0; I < NumTrampolines; ++I, OffsetToPtr -= TrampolineSize)
Trampolines[I] = CallIndirPCRel | ((OffsetToPtr - 6) << 16);
[Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer. This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
2015-02-17 01:18:38 +00:00
}
[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 03:36:38 +00:00
Error OrcX86_64_Base::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
unsigned MinStubs,
void *InitialPtrVal) {
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
// Stub format is:
//
// .section __orc_stubs
// stub1:
// jmpq *ptr1(%rip)
// .byte 0xC4 ; <- Invalid opcode padding.
// .byte 0xF1
// stub2:
// jmpq *ptr2(%rip)
//
// ...
//
// .section __orc_ptrs
// ptr1:
// .quad 0x0
// ptr2:
// .quad 0x0
//
// ...
const unsigned StubSize = IndirectStubsInfo::StubSize;
// Emit at least MinStubs, rounded up to fill the pages allocated.
unsigned PageSize = sys::Process::getPageSize();
unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
unsigned NumStubs = (NumPages * PageSize) / StubSize;
// Allocate memory for stubs and pointers in one call.
std::error_code EC;
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
2 * NumPages * PageSize, nullptr,
sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
if (EC)
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return errorCodeToError(EC);
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
// Create separate MemoryBlocks representing the stubs and pointers.
Add a sys::OwningMemoryBlock class, which is a sys::MemoryBlock that owns its underlying memory, and will automatically release it on destruction. Use this to tidy up the orc::IndirectStubsInfo class. llvm-svn: 251731
2015-10-31 00:55:32 +00:00
sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
NumPages * PageSize,
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
NumPages * PageSize);
// Populate the stubs page stubs and mark it executable.
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
uint64_t *Stub = reinterpret_cast<uint64_t *>(StubsBlock.base());
uint64_t PtrOffsetField = static_cast<uint64_t>(NumPages * PageSize - 6)
<< 16;
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
for (unsigned I = 0; I < NumStubs; ++I)
Stub[I] = 0xF1C40000000025ff | PtrOffsetField;
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
if (auto EC = sys::Memory::protectMappedMemory(
StubsBlock, sys::Memory::MF_READ | sys::Memory::MF_EXEC))
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return errorCodeToError(EC);
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
// Initialize all pointers to point at FailureAddress.
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
void **Ptr = reinterpret_cast<void **>(PtrsBlock.base());
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
for (unsigned I = 0; I < NumStubs; ++I)
Ptr[I] = InitialPtrVal;
[Orc] Turn OrcX86_64::IndirectStubsInfo into a template helper class: GenericIndirectStubsInfo. This will allow architecture support classes for other architectures to re-use this code. llvm-svn: 259549
2016-02-02 19:31:15 +00:00
StubsInfo = IndirectStubsInfo(NumStubs, std::move(StubsMem));
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return Error::success();
[Orc] Add support for emitting indirect stubs directly into the JIT target's memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
2015-10-19 17:43:51 +00:00
}
[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 03:36:38 +00:00
void OrcX86_64_SysV::writeResolverCode(uint8_t *ResolverMem,
JITReentryFn ReentryFn,
void *CallbackMgr) {
const uint8_t ResolverCode[] = {
// resolver_entry:
0x55, // 0x00: pushq %rbp
0x48, 0x89, 0xe5, // 0x01: movq %rsp, %rbp
0x50, // 0x04: pushq %rax
0x53, // 0x05: pushq %rbx
0x51, // 0x06: pushq %rcx
0x52, // 0x07: pushq %rdx
0x56, // 0x08: pushq %rsi
0x57, // 0x09: pushq %rdi
0x41, 0x50, // 0x0a: pushq %r8
0x41, 0x51, // 0x0c: pushq %r9
0x41, 0x52, // 0x0e: pushq %r10
0x41, 0x53, // 0x10: pushq %r11
0x41, 0x54, // 0x12: pushq %r12
0x41, 0x55, // 0x14: pushq %r13
0x41, 0x56, // 0x16: pushq %r14
0x41, 0x57, // 0x18: pushq %r15
0x48, 0x81, 0xec, 0x08, 0x02, 0x00, 0x00, // 0x1a: subq 0x208, %rsp
0x48, 0x0f, 0xae, 0x04, 0x24, // 0x21: fxsave64 (%rsp)
0x48, 0xbf, // 0x26: movabsq <CBMgr>, %rdi
// 0x28: Callback manager addr.
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x48, 0x8b, 0x75, 0x08, // 0x30: movq 8(%rbp), %rsi
0x48, 0x83, 0xee, 0x06, // 0x34: subq $6, %rsi
0x48, 0xb8, // 0x38: movabsq <REntry>, %rax
// 0x3a: JIT re-entry fn addr:
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xd0, // 0x42: callq *%rax
0x48, 0x89, 0x45, 0x08, // 0x44: movq %rax, 8(%rbp)
0x48, 0x0f, 0xae, 0x0c, 0x24, // 0x48: fxrstor64 (%rsp)
0x48, 0x81, 0xc4, 0x08, 0x02, 0x00, 0x00, // 0x4d: addq 0x208, %rsp
0x41, 0x5f, // 0x54: popq %r15
0x41, 0x5e, // 0x56: popq %r14
0x41, 0x5d, // 0x58: popq %r13
0x41, 0x5c, // 0x5a: popq %r12
0x41, 0x5b, // 0x5c: popq %r11
0x41, 0x5a, // 0x5e: popq %r10
0x41, 0x59, // 0x60: popq %r9
0x41, 0x58, // 0x62: popq %r8
0x5f, // 0x64: popq %rdi
0x5e, // 0x65: popq %rsi
0x5a, // 0x66: popq %rdx
0x59, // 0x67: popq %rcx
0x5b, // 0x68: popq %rbx
0x58, // 0x69: popq %rax
0x5d, // 0x6a: popq %rbp
0xc3, // 0x6b: retq
};
const unsigned ReentryFnAddrOffset = 0x3a;
const unsigned CallbackMgrAddrOffset = 0x28;
memcpy(ResolverMem, ResolverCode, sizeof(ResolverCode));
memcpy(ResolverMem + ReentryFnAddrOffset, &ReentryFn, sizeof(ReentryFn));
memcpy(ResolverMem + CallbackMgrAddrOffset, &CallbackMgr,
sizeof(CallbackMgr));
}
void OrcX86_64_Win32::writeResolverCode(uint8_t *ResolverMem,
JITReentryFn ReentryFn,
void *CallbackMgr) {
// resolverCode is similar to OrcX86_64 with differences specific to windows x64 calling convention:
// arguments go into rcx, rdx and come in reverse order, shadow space allocation on stack
const uint8_t ResolverCode[] = {
// resolver_entry:
0x55, // 0x00: pushq %rbp
0x48, 0x89, 0xe5, // 0x01: movq %rsp, %rbp
0x50, // 0x04: pushq %rax
0x53, // 0x05: pushq %rbx
0x51, // 0x06: pushq %rcx
0x52, // 0x07: pushq %rdx
0x56, // 0x08: pushq %rsi
0x57, // 0x09: pushq %rdi
0x41, 0x50, // 0x0a: pushq %r8
0x41, 0x51, // 0x0c: pushq %r9
0x41, 0x52, // 0x0e: pushq %r10
0x41, 0x53, // 0x10: pushq %r11
0x41, 0x54, // 0x12: pushq %r12
0x41, 0x55, // 0x14: pushq %r13
0x41, 0x56, // 0x16: pushq %r14
0x41, 0x57, // 0x18: pushq %r15
0x48, 0x81, 0xec, 0x08, 0x02, 0x00, 0x00, // 0x1a: subq 0x208, %rsp
0x48, 0x0f, 0xae, 0x04, 0x24, // 0x21: fxsave64 (%rsp)
0x48, 0xb9, // 0x26: movabsq <CBMgr>, %rcx
// 0x28: Callback manager addr.
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x48, 0x8B, 0x55, 0x08, // 0x30: mov rdx, [rbp+0x8]
0x48, 0x83, 0xea, 0x06, // 0x34: sub rdx, 0x6
0x48, 0xb8, // 0x38: movabsq <REntry>, %rax
// 0x3a: JIT re-entry fn addr:
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
// 0x42: sub rsp, 0x20 (Allocate shadow space)
0x48, 0x83, 0xEC, 0x20,
0xff, 0xd0, // 0x46: callq *%rax
// 0x48: add rsp, 0x20 (Free shadow space)
0x48, 0x83, 0xC4, 0x20,
0x48, 0x89, 0x45, 0x08, // 0x4C: movq %rax, 8(%rbp)
0x48, 0x0f, 0xae, 0x0c, 0x24, // 0x50: fxrstor64 (%rsp)
0x48, 0x81, 0xc4, 0x08, 0x02, 0x00, 0x00, // 0x55: addq 0x208, %rsp
0x41, 0x5f, // 0x5C: popq %r15
0x41, 0x5e, // 0x5E: popq %r14
0x41, 0x5d, // 0x60: popq %r13
0x41, 0x5c, // 0x62: popq %r12
0x41, 0x5b, // 0x64: popq %r11
0x41, 0x5a, // 0x66: popq %r10
0x41, 0x59, // 0x68: popq %r9
0x41, 0x58, // 0x6a: popq %r8
0x5f, // 0x6c: popq %rdi
0x5e, // 0x6d: popq %rsi
0x5a, // 0x6e: popq %rdx
0x59, // 0x6f: popq %rcx
0x5b, // 0x70: popq %rbx
0x58, // 0x71: popq %rax
0x5d, // 0x72: popq %rbp
0xc3, // 0x73: retq
};
const unsigned ReentryFnAddrOffset = 0x3a;
const unsigned CallbackMgrAddrOffset = 0x28;
memcpy(ResolverMem, ResolverCode, sizeof(ResolverCode));
memcpy(ResolverMem + ReentryFnAddrOffset, &ReentryFn, sizeof(ReentryFn));
memcpy(ResolverMem + CallbackMgrAddrOffset, &CallbackMgr,
sizeof(CallbackMgr));
}
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
void OrcI386::writeResolverCode(uint8_t *ResolverMem, JITReentryFn ReentryFn,
void *CallbackMgr) {
const uint8_t ResolverCode[] = {
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
// resolver_entry:
0x55, // 0x00: pushl %ebp
0x89, 0xe5, // 0x01: movl %esp, %ebp
0x54, // 0x03: pushl %esp
0x83, 0xe4, 0xf0, // 0x04: andl $-0x10, %esp
0x50, // 0x07: pushl %eax
0x53, // 0x08: pushl %ebx
0x51, // 0x09: pushl %ecx
0x52, // 0x0a: pushl %edx
0x56, // 0x0b: pushl %esi
0x57, // 0x0c: pushl %edi
0x81, 0xec, 0x18, 0x02, 0x00, 0x00, // 0x0d: subl $0x218, %esp
0x0f, 0xae, 0x44, 0x24, 0x10, // 0x13: fxsave 0x10(%esp)
0x8b, 0x75, 0x04, // 0x18: movl 0x4(%ebp), %esi
0x83, 0xee, 0x05, // 0x1b: subl $0x5, %esi
0x89, 0x74, 0x24, 0x04, // 0x1e: movl %esi, 0x4(%esp)
0xc7, 0x04, 0x24, 0x00, 0x00, 0x00,
0x00, // 0x22: movl <cbmgr>, (%esp)
0xb8, 0x00, 0x00, 0x00, 0x00, // 0x29: movl <reentry>, %eax
0xff, 0xd0, // 0x2e: calll *%eax
0x89, 0x45, 0x04, // 0x30: movl %eax, 0x4(%ebp)
0x0f, 0xae, 0x4c, 0x24, 0x10, // 0x33: fxrstor 0x10(%esp)
0x81, 0xc4, 0x18, 0x02, 0x00, 0x00, // 0x38: addl $0x218, %esp
0x5f, // 0x3e: popl %edi
0x5e, // 0x3f: popl %esi
0x5a, // 0x40: popl %edx
0x59, // 0x41: popl %ecx
0x5b, // 0x42: popl %ebx
0x58, // 0x43: popl %eax
0x8b, 0x65, 0xfc, // 0x44: movl -0x4(%ebp), %esp
0x5d, // 0x48: popl %ebp
0xc3 // 0x49: retl
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
};
[Orc] Add stack-realignment code to the i386 resolver function. The resolver uses the fxsave/fxrstor instructions, which require 16-byte alignment, to save SSE state to the stack. Since 16-byte alignment can't be assumed on all OSes (and all i386 OSes share this function) - add code to automatically bump the alignment to 16-bytes on entry to the function. llvm-svn: 261503
2016-02-21 22:50:26 +00:00
const unsigned ReentryFnAddrOffset = 0x2a;
const unsigned CallbackMgrAddrOffset = 0x25;
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
memcpy(ResolverMem, ResolverCode, sizeof(ResolverCode));
memcpy(ResolverMem + ReentryFnAddrOffset, &ReentryFn, sizeof(ReentryFn));
memcpy(ResolverMem + CallbackMgrAddrOffset, &CallbackMgr,
sizeof(CallbackMgr));
}
void OrcI386::writeTrampolines(uint8_t *TrampolineMem, void *ResolverAddr,
unsigned NumTrampolines) {
uint64_t CallRelImm = 0xF1C4C400000000e8;
uint64_t Resolver = reinterpret_cast<uint64_t>(ResolverAddr);
uint64_t ResolverRel =
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
Resolver - reinterpret_cast<uint64_t>(TrampolineMem) - 5;
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
uint64_t *Trampolines = reinterpret_cast<uint64_t *>(TrampolineMem);
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
for (unsigned I = 0; I < NumTrampolines; ++I, ResolverRel -= TrampolineSize)
Trampolines[I] = CallRelImm | (ResolverRel << 8);
}
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
Error OrcI386::emitIndirectStubsBlock(IndirectStubsInfo &StubsInfo,
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
unsigned MinStubs, void *InitialPtrVal) {
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
// Stub format is:
//
// .section __orc_stubs
// stub1:
// jmpq *ptr1
// .byte 0xC4 ; <- Invalid opcode padding.
// .byte 0xF1
// stub2:
// jmpq *ptr2
//
// ...
//
// .section __orc_ptrs
// ptr1:
// .quad 0x0
// ptr2:
// .quad 0x0
//
// ...
const unsigned StubSize = IndirectStubsInfo::StubSize;
// Emit at least MinStubs, rounded up to fill the pages allocated.
unsigned PageSize = sys::Process::getPageSize();
unsigned NumPages = ((MinStubs * StubSize) + (PageSize - 1)) / PageSize;
unsigned NumStubs = (NumPages * PageSize) / StubSize;
// Allocate memory for stubs and pointers in one call.
std::error_code EC;
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
auto StubsMem = sys::OwningMemoryBlock(sys::Memory::allocateMappedMemory(
2 * NumPages * PageSize, nullptr,
sys::Memory::MF_READ | sys::Memory::MF_WRITE, EC));
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
if (EC)
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return errorCodeToError(EC);
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
// Create separate MemoryBlocks representing the stubs and pointers.
sys::MemoryBlock StubsBlock(StubsMem.base(), NumPages * PageSize);
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
sys::MemoryBlock PtrsBlock(static_cast<char *>(StubsMem.base()) +
NumPages * PageSize,
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
NumPages * PageSize);
// Populate the stubs page stubs and mark it executable.
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
uint64_t *Stub = reinterpret_cast<uint64_t *>(StubsBlock.base());
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
uint64_t PtrAddr = reinterpret_cast<uint64_t>(PtrsBlock.base());
for (unsigned I = 0; I < NumStubs; ++I, PtrAddr += 4)
Stub[I] = 0xF1C40000000025ff | (PtrAddr << 16);
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
if (auto EC = sys::Memory::protectMappedMemory(
StubsBlock, sys::Memory::MF_READ | sys::Memory::MF_EXEC))
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return errorCodeToError(EC);
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
// Initialize all pointers to point at FailureAddress.
[ORC] clang-format code that was touched in r267457. NFC. Commit r267457 made a lot of type-substitutions threw off code formatting and alignment. This patch should tidy those changes up. llvm-svn: 267475
2016-04-25 21:21:20 +00:00
void **Ptr = reinterpret_cast<void **>(PtrsBlock.base());
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
for (unsigned I = 0; I < NumStubs; ++I)
Ptr[I] = InitialPtrVal;
StubsInfo = IndirectStubsInfo(NumStubs, std::move(StubsMem));
[ORC] Thread Error/Expected through the RPC library. This replaces use of std::error_code and ErrorOr in the ORC RPC support library with Error and Expected. This required updating the OrcRemoteTarget API, Client, and server code, as well as updating the Orc C API. This patch also fixes several instances where Errors were dropped. llvm-svn: 267457
2016-04-25 19:56:45 +00:00
return Error::success();
[Orc] Add lazy-JITting support for i386. This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
2016-02-10 01:02:33 +00:00
}
[Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code. NFC. llvm-svn: 230143
2015-02-21 20:44:36 +00:00
} // End namespace orc.
} // End namespace llvm.
Reference in New Issue Copy Permalink