[llvm-dev] JIT compiler and calls to existing functions

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 4 11:05:54 PDT 2016

Hi All,

For reasons already covered by Philip and others I prefer symbolic
resolution, rather than baking pointers into the IR. If you go that route
and you're using ORC you just need to add a line to your symbol resolver:

auto Resolver = createLambdaResolver(
    [&](const std::string &Name) {
      if (auto Sym = findMangledSymbol(Name))
        return RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags());

      if (Name == "sin")
        return RuntimeDyld::SymbolInfo(

      return RuntimeDyld::SymbolInfo(nullptr);

    [](const std::string &S) { return nullptr; });

If you have a large number of in-process symbols you'd like to supply you
can substitute a StringMap lookup.

See llvm/examples/Kaleidoscope/include/KaleidoscopeJIT.h.


On Wed, Mar 30, 2016 at 8:08 AM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> We use an explicit relocation step to deal with this.  We generate code
> into a temporary memory location, then relocate it into a reserved area of
> memory which is always within a small relative offset of other interesting
> code.  This allows us to get pc relative calls.
> Philip
> On 03/30/2016 05:53 AM, Matt Godbolt wrote:
> For what it's worth we did a similar thing, but
> overrode RTDyldMemoryManager directly This allowed us to control where the
> RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use
> small memory model and avoid the mov rax, xxxxxxx; call rax code generated
> for x86)*, and also override findSymbol() to have the same behaviour as
> described in 4).
> --matt
> * later issues in not always being able to allocate low ram caused us to
> drop this feature. I wish we could fix the "call rax"es :)
> On Tue, Mar 29, 2016 at 6:51 PM Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> There is no documentation I know of.  Rough sketch:
>> 1) Create a subclass of SectionMemoryManager
>> 2) Create an instance of this class and add it the EngineBuilder via
>> setMCJITMemoryManager
>> (Make sure everything runs without changes)
>> 3) Override the getSymbolAddress method, have your implementation call
>> the base classes impl
>> (Make sure everything runs without changes)
>> 4) Add handling to map name->address for any custom functions you want.
>> On 03/28/2016 09:18 PM, Russell Wallace wrote:
>> True, I care more about how fast the code runs than how long it takes to
>> compile it. So if the symbolic approach enables better code generation,
>> that is a very significant advantage from my perspective.
>> Is there any example code or documentation you can point to for details
>> about how to implement the symbolic approach? Is it similar to any of the
>> versions of Kaleidoscope or any other extant tutorial?
>> On Tue, Mar 29, 2016 at 5:07 AM, Philip Reames <
>> <listmail at philipreames.com>listmail at philipreames.com> wrote:
>>> Other advantages of keeping things symbolic:
>>> 1) You can use function attributes to provide optimization or semantic
>>> information.
>>> 2) Linking modules works as expected when one of them contains the
>>> definition.
>>> 3) You can get better code generation (i.e. pc relative addressing for
>>> local symbols, etc..)
>>> If the inttoptr scheme makes you happy, go for it.  I'm not telling you
>>> its wrong, merely that there's another approach you should consider which
>>> has it's own advantages.
>>> Philip
>>> p.s. Your point about compiling faster is off base.  Not because you're
>>> wrong, but because if you're trying to optimize for compile speed at that
>>> granularity, you really don't want to be using LLVM (or just about any
>>> framework.)  LLVM does not make a good first tier JIT.  It's makes a great
>>> high tier JIT, but if you really really care about compile time, it is not
>>> the appropriate answer.
>>> On 03/28/2016 08:57 PM, Russell Wallace wrote:
>>> Ah! Okay then, so you are saying something substantive that I think I
>>> disagree with, but that could be because there are relevant issues I don't
>>> understand.
>>> My reasoning is, I've already got a pointer to the function I want the
>>> generated code to call, so I just supply that pointer, it looks ugly on a
>>> microscopic scale because there are a couple of lines of casts to shepherd
>>> it through the type system, but on an even slightly larger scale it's as
>>> simple and elegant as it gets: I supply a 64-bit machine word that gets
>>> compiled into the object code, there are no extra layers of machinery to go
>>> wrong, no nonlocal effects to understand, no having to wonder about whether
>>> anything depends on symbol information that might vary between debug and
>>> release builds or between the vendor compiler and clang or between Windows
>>> and Linux; if it works once, it will work the same way every time. As a
>>> bonus, it will compile slightly faster.
>>> Keeping things symbolic - you're saying the advantage is the
>>> intermediate code is easier to debug because a dump will say 'call print'
>>> instead of 'call function at 123456'? I can see that being a real advantage
>>> but as of right now it doesn't jump out at me as necessarily outweighing
>>> the advantages of the direct pointer method.
>>> On Tue, Mar 29, 2016 at 4:37 AM, Philip Reames <
>>> <listmail at philipreames.com>listmail at philipreames.com> wrote:
>>>> I think our use cases are actually quite similar.  Part of generating
>>>> the in memory executable code is resolving all the symbolic symbols and
>>>> relocations.  The details of this are mostly hidden from you by the MCJIT
>>>> interface, but it's this step I was referring to as "link time".
>>>> The way to think of MCJIT: generate object file, incrementally link,
>>>> run dynamic loader, but do it all in memory without round tripping through
>>>> disk or explicit files.
>>>> Philip
>>>> On Mar 28, 2016, at 7:25 PM, Russell Wallace <
>>>> <russell.wallace at gmail.com>russell.wallace at gmail.com> wrote:
>>>> Right, but when you say link time, the JIT compiler I'm writing works
>>>> the way openJDK or v8 do, it reads a script, JIT compiles it into memory
>>>> and runs the code in memory without ever writing anything to disk (an
>>>> option for ahead of time compilation may come later, but that will be a
>>>> while down the road), so we might be doing different things?
>>>> On Tue, Mar 29, 2016 at 2:59 AM, Philip Reames <
>>>> <listmail at philipreames.com>listmail at philipreames.com> wrote:
>>>>> The option we use is to have a custom memory manager, override the
>>>>> getPointerToNamedFunction function, and provide the pointer to the external
>>>>> function at link time.  The inttoptr scheme works fairly well, but it does
>>>>> make for some pretty ugly and sometimes hard to analyze IR.  I recommend
>>>>> leaving everything symbolic until link time if you can.
>>>>> Philip
>>>>> On 03/28/2016 06:33 PM, Russell Wallace via llvm-dev wrote:
>>>>> That seems to work, thanks! The specific code I ended up with to call
>>>>> int64_t print(int64_t) looks like:
>>>>>         auto f = builder.CreateIntToPtr(
>>>>>             ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)),
>>>>>             PointerType::getUnqual(FunctionType::get(
>>>>>                 builder.getInt64Ty(), {builder.getInt64Ty()}, false)));
>>>>>         return builder.CreateCall(f, args);
>>>>> On Mon, Mar 28, 2016 at 1:40 PM, Caldarale, Charles R <
>>>>> <Chuck.Caldarale at unisys.com>Chuck.Caldarale at unisys.com> wrote:
>>>>>> > From: llvm-dev [mailto: <llvm-dev-bounces at lists.llvm.org>
>>>>>> llvm-dev-bounces at lists.llvm.org]
>>>>>> > On Behalf Of Russell Wallace via llvm-dev
>>>>>> > Subject: [llvm-dev] JIT compiler and calls to existing functions
>>>>>> > In the context of a JIT compiler, what's the recommended way to
>>>>>> generate a call to an
>>>>>> > existing function, that is, not one that you are generating
>>>>>> on-the-fly with LLVM, but
>>>>>> > one that's already linked into your program? For example the cosine
>>>>>> function (from the
>>>>>> > standard math library); the Kaleidoscope tutorial recommends
>>>>>> looking it up by name with
>>>>>> > dlsym("cos"), but it seems to me that it should be possible to use
>>>>>> a more efficient and
>>>>>> > portable solution that takes advantage of the fact that you already
>>>>>> have an actual pointer
>>>>>> > to cos, even if you haven't linked with debugging symbols.
>>>>>> Perhaps not the most elegant, but we simply use the
>>>>>> IRBuilder.CreateIntToPtr() method to construct the Callee argument for
>>>>>> IRBuilder.CreateCall().  The first argument for CreateIntToPtr() comes from
>>>>>> ConstantInt::get(I64, uintptr_t(ptr)), while the second is a function type
>>>>>> pointer defined by using PointerType::get() on the result of
>>>>>> FunctionType::get() with the appropriate function signature.
>>>>>>  - Chuck
>>>>> _______________________________________________
>>>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> 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/20160404/13578a18/attachment.html>

More information about the llvm-dev mailing list