[PATCH] D110990: [Orc] Fix global variable destructor function support when --jit-kind=orc-lazy
luxufan via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 6 00:48:24 PDT 2021
StephenFan marked an inline comment as done.
StephenFan added inline comments.
================
Comment at: llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:479
+ else
+ raw_string_ostream(InitOrDeInitFunctionName) << M.getModuleIdentifier();
+
----------------
lhames wrote:
> It would be good to use a `DeInitFunctionPrefix` here (along the same lines as `InitFunctionPrefix`).
>
> Once the deinit functions are named with a known prefix we can look them up in `GenericLLVMIRPlatformSupport::notifyAdding` and add them to the DeInitFunctions map automatically. This will make destructors work from cached objects. This could be done in this patch, or in a follow-up.
>
> Once the deinit functions are named with a known prefix we can look them up in `GenericLLVMIRPlatformSupport::notifyAdding` and add them to the DeInitFunctions map automatically. This will make destructors work from cached objects. This could be done in this patch, or in a follow-up.
>
I have a question that what do cached objects mean in ORC ? After looking through the source code, I found that when define the symbol in JITDylib, the `notifyAdding` will be called, and when emit the symbol (MaterializationUnit), the layer will call the transform function to transform the module, in which the `GlobalCtorDtorScraper::operator()` will be called, is my understand right ?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110990/new/
https://reviews.llvm.org/D110990
More information about the llvm-commits
mailing list