Displaying 3 results from an estimated 3 matches for "getresponsibilitysetwithlegacyfn".
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...>
> if (!Finalized)
> return JITSymbol(getSymbolMaterializer(Name),
> SymEntry->second.getFlags());
>
> That's not a null symbol, it's a lazy symbol with a materializer attached.
> It *should* compare non-null in the following test
> in getResponsibilitySetWithLegacyFn, which in turn should cause it to be
> added to the responsibility set:
>
> if (JITSymbol Sym = FindSymbol(*S)) {
> if (!Sym.getFlags().isStrong())
> Result.insert(S); //
> <- _ZNSt6vectorIfSaIfEE17_M_default_appendEm should be added here.
>...
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...s Lang could confirm?)
We use createLegacyLookupResolver() to create our symbol resolver,
passing it a lookup function. Amongst other things, our function calls
LegacyRTDyldObjectLinkingLayer::findSymbol() to look up symbols in the
JIT.
When a module is finalized, the legacy lookup resolver calls
getResponsibilitySetWithLegacyFn() to find any symbols with weak
linkage (e.g. function templates) that need to be materialized; that
function calls our symbol resolver, which calls
LegacyRTDyldObjectLinkingLayer::findSymbol(). The problem is,
findSymbol() returns a null JITSymbol (address 0) if the symbol has
not been materialize...
2019 Sep 15
2
Orc JIT vs. implicit template instanciation in LLVM 8
Well, I agree the front end must be responsible for (not)
instantiating the function templates. However the problem shows up
only when JIT compiling, for some reason, and only with LLVM 8. Is
there perhaps something else that needs to be done before resolving
symbols, in addition to running constructors, to ensure that
instantiated function templates are taken into account?
Or perhaps there is