Removes LinkGraph's PointerSize and Endianness members and uses the triple to find these values instead. Also removes some redundant Triple copies.
Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning on the boundary between JITLink and ORC, and allows pointer comparisons (rather than string comparisons) between Symbol names. This should improve the performance and readability of code that bridges between JITLink and ORC (e.g. ObjectLinkingLayer and ObjectLinkingLayer::Plugins). To enable use of SymbolStringPtr a std::shared_ptr<SymbolStringPool> is added to LinkGraph and threaded through to its construction sites in LLVM and Bolt. All LinkGraphs that are to have symbol names compared by pointer equality must point to the same SymbolStringPool instance, which in ORC sessions should be the pool attached to the ExecutionSession. --------- Co-authored-by: Lang Hames <lhames@gmail.com>
Most ORC APIs work with ExecutorAddr by default since 8b1771bd9f3, so we don't need to wrap these values in ExecutorAddr(...) calls any more.
ExecutorAddr was introduced in b8e5f918166 as an eventual replacement for JITTargetAddress. ExecutorSymbolDef is introduced in this patch as a replacement for JITEvaluatedSymbol: ExecutorSymbolDef is an (ExecutorAddr, JITSymbolFlags) pair, where JITEvaluatedSymbol was a (JITTargetAddress, JITSymbolFlags) pair. A number of APIs had already migrated from JITTargetAddress to ExecutorAddr, but many of ORC's internals were still using the older type. This patch aims to address that. Some public APIs are affected as well. If you need to migrate your APIs you can use the following operations: * ExecutorAddr::toPtr replaces jitTargetAddressToPointer and jitTargetAddressToFunction. * ExecutorAddr::fromPtr replace pointerToJITTargetAddress. * ExecutorAddr(JITTargetAddress) creates an ExecutorAddr value from a JITTargetAddress. * ExecutorAddr::getValue() creates a JITTargetAddress value from an ExecutorAddr. JITTargetAddress and JITEvaluatedSymbol will remain in JITSymbol.h for now, but the aim will be to eventually deprecate and remove these types (probably when MCJIT and RuntimeDyld are deprecated).
This patch adds resolver, indirection and trampoline stubs for loongarch64, allowing lazy compilation to work. It assumes hard float feature exists. Depends on D141036 Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D141102
This was left in by accident, and caused unchecked-error assertions during program termination in BuildingAJIT-Ch4.
This adds resolver, indirection and trampoline stubs for riscv64, allowing lazy compilation to work. It assumes hard float extension exists. I don't know the proper way to detect it as Triple doesn't provide the interface to check riscv +f +d abi. I am also not sure if orclazy tests should be enabled because lli needs an additional -codemodel=melany for tests to pass. Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D122543
Without this, EPCIndirectionUtils::getResolverBlockAddr (and lazy compilation via EPC) won't work. No test case: lli is still using LocalLazyCallThroughManager. I'll revisit this soon when I look at adding lazy compilation support to the ORC runtime.
This re-applies 133f86e95492b2a00b944e070878424cfa73f87c, which was reverted in c5965a411c635106a47738b8d2e24db822b7416f while I investigated bot failures. The original failure contained an arithmetic conversion think-o (on line 419 of EHFrameSupport.cpp) that could cause failures on 32-bit platforms. The issue should be fixed in this patch.