aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/XCOFFObjectFile.cpp
diff options
context:
space:
mode:
authorLang Hames <lhames@gmail.com>2025-10-13 12:33:16 +1100
committerGitHub <noreply@github.com>2025-10-13 12:33:16 +1100
commit7381558ef8b8639831dfdedf7edbd5e635afc85e (patch)
tree9420b5ffee84d75afd7a19fff7ed6f4a659d7e08 /llvm/lib/Object/XCOFFObjectFile.cpp
parent8d03a37b9844070b6ccd83aa7cc8b28e91f8d213 (diff)
downloadllvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.zip
llvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.tar.gz
llvm-7381558ef8b8639831dfdedf7edbd5e635afc85e.tar.bz2
[orc-rt] Rename SimpleNativeMemoryMap finalize & deallocate. NFCI. (#163114)
This commit renames the "finalize" operation to "initialize", and "deallocate" to "deinitialize". The new names are chosen to better fit the point of view of the ORC-runtime and executor-process: After memory is *reserved* it can be *initialized* with some content, and *deinitialized* to return that memory to the reserved region. This seems more understandable to me than the original scheme, which named these operations after the controller-side JITLinkMemoryManager operations that they partially implemented. I.e. SimpleNativeMemoryMap::finalize implemented the final step of JITLinkMemoryManager::finalize, initializing the memory in the executor; and SimpleNativeMemoryMap::deallocate implemented the final step of JITLinkMemoryManager::deallocate, running dealloc actions and releasing the finalized region. The proper way to think of the relationship between these operations now is that: 1. The final step of finalization is to initialize the memory in the executor. 2. The final step of deallocation is to deinitialize the memory in the executor.
Diffstat (limited to 'llvm/lib/Object/XCOFFObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions