Displaying 3 results from an estimated 3 matches for "getsymbolmaterializer".
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...ddress 0) if the
>> symbol has not been materialized yet. And naturally it hasn't, since we are
>> trying to determine which symbols need to be materialized...
>
>
> If Finalized == false, then we should be hitting this:
>
> 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
> a...
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...f the symbol has
not been materialized yet. And naturally it hasn't, since we are
trying to determine which symbols need to be materialized...
My quick fix is to change these lines in
LegacyRTDyldObjectLinkingLayerBase::LinkedObject::getSymbol():
if (!Finalized)
return JITSymbol(getSymbolMaterializer(Name),
SymEntry->second.getFlags());
to:
if (!Finalized || SymEntry->second.getAddress() == 0)
return JITSymbol(getSymbolMaterializer(Name),
SymEntry->second.getFlags());
That works for me, but I am not sure it is the right...
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