[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