[llvm-dev] [ORC JIT] Exposing IndirectStubsManager from CompileOnDemandLayer.h

Sean Ogden via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 29 16:17:07 PDT 2016


It does work.  I just tested it on my JIT.  Thanks!

As for the part that couples them too tightly, would you recommend I just
keep my own specialized version of CompileOnDemandLayer.h that includes
this functionality, or do you have any ideas for a cleaner way to do this?
I've noticed a couple of people asking for support for updating stub
pointers for functions that are optimized at runtime, and I'd be willing to
work on adding that support.

On Fri, Jul 29, 2016 at 6:53 PM Lang Hames <lhames at gmail.com> wrote:

> Hi Sean,
>
> This is great, but it couples LogicalDylib too tightly to
> CompileOnDemandLayer. Does this alternative implementation of
> getLogicalModuleResourcesForSymbol work for you (unfortunately I don't
> have a local test case for this yet):
>
>
>
>
>
>   LogicalModuleResources*
>   getLogicalModuleResourcesForSymbol(const std::string &Name,
>                                      bool ExportedSymbolsOnly) {
>     for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end();
>          LMI != LME; ++LMI)
>       if (auto Sym = LMI->Resources.findSymbol(Name, ExportedSymbolsOnly))
>         return &LMI->Resources;
>     return nullptr;
>   }
>
> If so I'd be happy to commit this on your behalf.
>
> It might be nice to plumb support for this to the Orc C-bindings too: that
> would enable testing of this via the C-Bindings unit tests.
>
> Thanks very much for working on this!
>
> Cheers,
> Lang.
>
>
>
> On Fri, Jul 29, 2016 at 8:10 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> +Lang Hames <lhames at gmail.com>, Master Regent of the Three <No, Two sir>
>> JITs
>>
>> On Thu, Jul 28, 2016 at 12:31 PM Sean Ogden via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> I needed to be able to update stub pointers for hot functions that get
>>> recompiled in a lazy JIT that uses CompileOnDemandLayer.  In order to do
>>> this I added a method that allows pointers to be updated but does not
>>> expose any of the other internals of the COD layer.
>>>
>>> Does anyone have a cleaner way to do this?  Has something to facilitate
>>> this already been added?  Would it be possible to merge this in?
>>>
>>> diff --git a/CompileOnDemandLayer.h b/CompileOnDemandLayer.h
>>> index bd192b8..4aa3362 100644
>>> --- a/CompileOnDemandLayer.h
>>> +++ b/CompileOnDemandLayer.h
>>> @@ -429,6 +429,28 @@ private:
>>>      return CalledAddr;
>>>    }
>>>
>>> +public:
>>> +  TargetAddress updatePointer(std::string FuncName, TargetAddress
>>> FnBodyAddr) {
>>> +    //Find out which logical dylib contains our symbol
>>> +    auto LDI = LogicalDylibs.begin();
>>> +    for (auto LDE = LogicalDylibs.end(); LDI != LDE; ++LDI) {
>>> +        if (auto LMResources =
>>> LDI->getLogicalModuleResourcesForSymbol(FuncName, false)) {
>>> +            Module &SrcM = LMResources->SourceModule->getResource();
>>> +            std::string CalledFnName = mangle(FuncName,
>>> SrcM.getDataLayout());
>>> +            if (auto EC =
>>> LMResources->StubsMgr->updatePointer(CalledFnName, FnBodyAddr)) {
>>> +                return 0;
>>> +            }
>>> +            else
>>> +                return FnBodyAddr;
>>> +        }
>>> +    }
>>> +    return 0;
>>> +  }
>>> +
>>> +private:
>>>
>>>
>>> diff --git a/LogicalDylib.h b/LogicalDylib.h
>>> index 84e3bf5..2e35cfd 100644
>>> --- a/LogicalDylib.h
>>> +++ b/LogicalDylib.h
>>> @@ -17,6 +17,8 @@
>>>  #include "JITSymbol.h"
>>>  #include <string>
>>>  #include <vector>
>>> +#include "llvm/IR/Mangler.h"
>>> +#include "llvm/Support/raw_ostream.h"
>>>
>>>  namespace llvm {
>>>  namespace orc {
>>> @@ -77,6 +79,24 @@ public:
>>>      return LMH->Resources;
>>>    }
>>>
>>> +  static std::string mangle(StringRef Name, const DataLayout &DL) {
>>> +    std::string MangledName;
>>> +    {
>>> +      raw_string_ostream MangledNameStream(MangledName);
>>> +      Mangler::getNameWithPrefix(MangledNameStream, Name, DL);
>>> +    }
>>> +    return MangledName;
>>> +  }
>>> +
>>> +  LogicalModuleResources* getLogicalModuleResourcesForSymbol(const
>>> std::string &Name, bool ExportedSymbolsOnly) {
>>> +    for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end();
>>> +         LMI != LME; ++LMI)
>>> +      if (auto Sym = findSymbolInLogicalModule(LMI,
>>> mangle(Name,LMI->Resources.SourceModule->getResource().getDataLayout()),
>>> ExportedSymbolsOnly))
>>> +          return &LMI->Resources;
>>> +    return nullptr;
>>> +  }
>>> +
>>> +
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160729/eba54386/attachment.html>


More information about the llvm-dev mailing list