[ORC] Return ExecutorAddrs rather than JITEvaluatedSymbols from LLJIT::lookup.Clients don't care about linkage, and ExecutorAddr is much more ergonomic.
Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.Adds explicit narrowing casts to JITLinkMemoryManager.cpp.Honors -slab-address option in llvm-jitlink.cpp, which was accide
Re-apply e50aea58d59, "Major JITLinkMemoryManager refactor". with fixes.Adds explicit narrowing casts to JITLinkMemoryManager.cpp.Honors -slab-address option in llvm-jitlink.cpp, which was accidentallydropped in the refactor.This effectively reverts commit 6641d29b70993bce6dbd7e0e0f1040753d38842f.
show more ...
Revert "[JITLink][ORC] Major JITLinkMemoryManager refactor."This reverts commit e50aea58d59c8cfae807a7fee21c4227472c0678 while Iinvestigate bot failures.
[JITLink][ORC] Major JITLinkMemoryManager refactor.This commit substantially refactors the JITLinkMemoryManager API to: (1) addasynchronous versions of key operations, (2) give memory manager impl
[JITLink][ORC] Major JITLinkMemoryManager refactor.This commit substantially refactors the JITLinkMemoryManager API to: (1) addasynchronous versions of key operations, (2) give memory manager implementationsfull control over link graph address layout, (3) enable more efficient trackingof allocated memory, and (4) support "allocation actions" and finalize-lifetimememory.Together these changes provide a more usable API, and enable more powerful andefficient memory manager implementations.To support these changes the JITLinkMemoryManager::Allocation inner class hasbeen split into two new classes: InFlightAllocation, and FinalizedAllocation.The allocate method returns an InFlightAllocation that tracks memory (bothworking and executor memory) prior to finalization. The finalize method returnsa FinalizedAllocation object, and the InFlightAllocation is discarded. BreakingAllocation into InFlightAllocation and FinalizedAllocation allowsInFlightAllocation subclassses to be written more naturally, and FinalizedAllocto be implemented and used efficiently (see (3) below).In addition to the memory manager changes this commit also introduces a newMemProt type to represent memory protections (MemProt replaces use ofsys::Memory::ProtectionFlags in JITLink), and a new MemDeallocPolicy type thatcan be used to indicate when a section should be deallocated (see (4) below).Plugin/pass writers who were using sys::Memory::ProtectionFlags will have toswitch to MemProt -- this should be straightworward. Clients with out-of-treememory managers will need to update their implementations. Clients usingin-tree memory managers should mostly be able to ignore it.Major features:(1) More asynchrony:The allocate and deallocate methods are now asynchronous by default, withsynchronous convenience wrappers supplied. The asynchronous versions allowclients (including JITLink) to request and deallocate memory without blocking.(2) Improved control over graph address layout:Instead of a SegmentRequestMap, JITLinkMemoryManager::allocate now takes areference to the LinkGraph to be allocated. The memory manager is responsiblefor calculating the memory requirements for the graph, and laying out the graph(setting working and executor memory addresses) within the allocated memory.This gives memory managers full control over JIT'd memory layout. For clientsthat don't need or want this degree of control the new "BasicLayout" utility canbe used to get a segment-based view of the graph, similar to the one provided bySegmentRequestMap. Once segment addresses are assigned the BasicLayout::applymethod can be used to automatically lay out the graph.(3) Efficient tracking of allocated memory.The FinalizedAlloc type is a wrapper for an ExecutorAddr and requires only64-bits to store in the controller. The meaning of the address held by theFinalizedAlloc is left up to the memory manager implementation, but theFinalizedAlloc type enforces a requirement that deallocate be called on anynon-default values prior to destruction. The deallocate method takes avector<FinalizedAlloc>, allowing for bulk deallocation of many allocations in asingle call.Memory manager implementations will typically store the address of someallocation metadata in the executor in the FinalizedAlloc, as holding thismetadata in the executor is often cheaper and may allow for clean deallocationeven in failure cases where the connection with the controller is lost.(4) Support for "allocation actions" and finalize-lifetime memory.Allocation actions are pairs (finalize_act, deallocate_act) of JITTargetAddresstriples (fn, arg_buffer_addr, arg_buffer_size), that can be attached to afinalize request. At finalization time, after memory protections have beenapplied, each of the "finalize_act" elements will be called in order (skippingany elements whose fn value is zero) as((char*(*)(const char *, size_t))fn)((const char *)arg_buffer_addr, (size_t)arg_buffer_size);At deallocation time the deallocate elements will be run in reverse order (againskipping any elements where fn is zero).The returned char * should be null to indicate success, or a non-nullheap-allocated string error message to indicate failure.These actions allow finalization and deallocation to be extended to includeoperations like registering and deregistering eh-frames, TLS sections,initializer and deinitializers, and language metadata sections. Previously theseoperations required separate callWrapper invocations. Compared to callWrapperinvocations, actions require no extra IPC/RPC, reducing costs and eliminatinga potential source of errors.Finalize lifetime memory can be used to support finalize actions: Sections withfinalize lifetime should be destroyed by memory managers immediately afterfinalization actions have been run. Finalize memory can be used to supportfinalize actions (e.g. with extra-metadata, or synthesized finalize actions)without incurring permanent memory overhead.
[Orc] Add basic OrcV2 C bindings and example.Renames the llvm/examples/LLJITExamples directory to llvm/examples/OrcV2Examplessince it is becoming a home for all OrcV2 examples, not just LLJIT.Se
[Orc] Add basic OrcV2 C bindings and example.Renames the llvm/examples/LLJITExamples directory to llvm/examples/OrcV2Examplessince it is becoming a home for all OrcV2 examples, not just LLJIT.See http://llvm.org/PR31103.