[PATCH] D146183: [JITLink][ORC] Rename MemDeallocPolicy to MemLifetimePolicy, add NoAlloc option.

[Lang Hames via Phabricator via llvm-commits]

lhames created this revision.
lhames added reviewers: pchintalapudi, sgraenitz, v.g.vassilev, sunho.
Herald added subscribers: hiraditya, arichardson.
Herald added a project: All.
lhames requested review of this revision.
Herald added a project: LLVM.

The original MemDeallocPolicy options were 'Standard' (the allocated memory
should live until the FinalizedAlloc is deallocated, or the InFlightAlloc is
abandoned) and 'Finalize' (the allocated memory should live until all finalize
actions have been run).

The new NoAlloc option indicates that the section should not have memory
allocated for it at all, and should be ignored by the JITLinkMemoryManager
(the memory manager should skip such sections entirely, allocating neither
working memory nor executor address space to them). The NoAlloc option is
intended to support metadata sections (e.g. debug info) that we want to keep in
the graph and have fixed up if necessary, but don't want allocated or
transmitted to the executor (or we want that transmission to be managed
manually by plugins).

Since NoAlloc blocks do not have working memory allocated for them by the
JITLinkMemoryManager, clients wishing to mutate their memory should call the
`Block::getMutableMemory(G)` method on them. This will copy the Block's content
to memory allocated on G's allocator (on first call, subsequent calls just
return the existing allocation(). If the block's content is not copied to
mutable memory prior to the fixup phase the generic link algorithm will do this
automatically. Block content in NoAlloc sections will remain available until
the LinkGraph is destroyed.

The addresses of blocks in NoAlloc sections are initialized by the LinkGraph
creator (a LinkGraphBuilder, if the graph is generated from an object file),
and is should not be modified by the JITLinkMemoryManager. Plugins are
responsible for updating addresses if they add/remove content from these
sections.

Blocks in Standard and Finalize sections should never contain edges pointing to
NonAlloc sections, as the addresses for these blocks aren't meaningful. The
LinkGraphBuilders should check this property in the input object files, and
plugins are required to preserve it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146183

Files:
  llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h
  llvm/include/llvm/ExecutionEngine/JITLink/JITLinkMemoryManager.h
  llvm/include/llvm/ExecutionEngine/Orc/Shared/MemoryFlags.h
  llvm/include/llvm/ExecutionEngine/Orc/Shared/TargetProcessControlTypes.h
  llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.h
  llvm/lib/ExecutionEngine/JITLink/JITLinkMemoryManager.cpp
  llvm/lib/ExecutionEngine/Orc/EPCGenericRTDyldMemoryManager.cpp
  llvm/lib/ExecutionEngine/Orc/MemoryMapper.cpp
  llvm/lib/ExecutionEngine/Orc/TargetProcess/ExecutorSharedMemoryMapperService.cpp
  llvm/lib/ExecutionEngine/Orc/TargetProcess/SimpleExecutorMemoryManager.cpp
  llvm/tools/llvm-jitlink/llvm-jitlink.cpp
  llvm/unittests/ExecutionEngine/JITLink/LinkGraphTests.cpp
  llvm/unittests/ExecutionEngine/Orc/EPCGenericJITLinkMemoryManagerTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D146183.505672.patch
Type: text/x-patch
Size: 24252 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230316/2e76ef5f/attachment.bin>