[PATCH] D110990: [Orc] Fix global variable destructor function support when --jit-kind=orc-lazy

[luxufan via Phabricator via llvm-commits]

StephenFan added inline comments.


================
Comment at: llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:479
+      else
+        raw_string_ostream(InitOrDeInitFunctionName) << M.getModuleIdentifier();
+
----------------
lhames wrote:
> StephenFan wrote:
> > 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 ?
> Hi Stephen,
> 
> > I have a question that what do cached objects mean in ORC ?
> 
> By "cached objects", we mean stored object files that were created by an `ObjectCache` instance from LLVM IR that was added to the JIT.
> 
> In MCJIT we used to discover constructors at the IR layer only by looking for llvm.global_ctors instances. In `GenericLLVMIRPlatformSupport` we rewrite `llvm.global_ctors` instances into functions with reserved names that we can look for at the object level. We could do the same thing with `llvm.global_dtors`.
> 
> This approach is a stop-gap until we have generic JITLink support on all platforms. Once we have JITLink everywhere we can remove `GenericLLVMIRPlatformSupport` entirely.
Thanks for your explanation! @lhames 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110990/new/

https://reviews.llvm.org/D110990