[llvm-dev] Question regarding GlobalMappingLayer in LLVM 5

[Lang Hames via llvm-dev]

Hi Brian,

This has been fixed in r314374. You should be able to apply that patch
cleanly to 5.0.

Cheers,
Lang.


On Wed, Sep 27, 2017 at 6:32 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Brian,
>
> Yes - I believe you're correct. I'm working on a fix and extra test
> coverage now. In the meantime, I believe you should be able to fix the
> signatures in your copy and everything should "just work".
>
> Cheers,
> Lang.
>
> On Fri, Sep 22, 2017 at 2:04 PM, Brian Kahne via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>>
>>
>> I’m attempting to port some code which uses the GlobalMappingLayer in the
>> Orc JIT.  This code worked fine in LLVM 4, but I’m getting a compile error
>> with LLVM 5.  I think the problem is that this layer hasn’t been modified
>> to account for some of the changes made in LLVM 5, but I wanted to make
>> sure that I wasn’t missing something.
>>
>>
>>
>> I have code which looks like this:
>>
>>
>>
>>       ModuleHandle addModule(std::unique_ptr<Module> M) {
>>
>>         // Build our symbol resolver:
>>
>>         // Lambda 1: Look back into the JIT itself to find symbols that
>> are part of
>>
>>         //           the same "logical dylib".
>>
>>         // Lambda 2: Search for external symbols in the host process.
>>
>>         auto Resolver = createLambdaResolver(
>>
>>                                              [&](const std::string
>> &Name) {
>>
>>                                                if (auto Sym =
>> OptimizeLayer.findSymbol(Name, false))
>>
>>                                                  return Sym;
>>
>>                                                return JITSymbol(nullptr);
>>
>>                                              },
>>
>>                                              [](const std::string &Name)
>> {
>>
>>                                                if (auto SymAddr =
>>
>>
>> RTDyldMemoryManager::getSymbolAddressInProcess(Name))
>>
>>                                                  return
>> JITSymbol(SymAddr, JITSymbolFlags::Exported);
>>
>>                                                return JITSymbol(nullptr);
>>
>>                                              });
>>
>>
>>
>>
>>
>>         // Add the set to the JIT with the resolver we created above and
>> a newly
>>
>>         // created SectionMemoryManager.
>>
>>         return OptimizeLayer.addModule(std::move(M),
>>
>>                                                 std::move(Resolver));
>>
>>       }
>>
>>
>>
>> Where OptimizeLayer is:
>>
>>
>>
>>       IRTransformLayer<GlobalMappingLayerT, OptimizeFunction>
>> OptimizeLayer;
>>
>>
>>
>> This worked fine with LLVM 4, but causes a problem in LLVM 5.  It looks
>> like the issue is that IRTransformLayer::addModule returns an
>> Expected<ModuleT>, whereas GlobalMappingLayer returns just a
>> ModuleHandleT.  However, in LLVM 4, IRTransformLayer::addModuleSet returned
>> a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a
>> ModuleSetHandleT, so the types matched up.  In LLVM 5, the
>> CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but
>> not GlobalMappingLayer.
>>
>>
>>
>> Does that explanation seem correct, or am I missing something?
>>
>>
>>
>> Thx,
>>
>>
>>
>> -brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/5ccab0aa/attachment.html>