similar to: JIT compiler and calls to existing functions

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

> From: llvm-dev [mailto: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

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

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

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

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

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

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

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

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

Can't the code generator do this opportunistically? That is, generate the more compact instruction sequence if the address happens to be within four gigabytes, otherwise generate the longer form? On Wed, Mar 30, 2016 at 1:53 PM, Matt Godbolt <matt at godbolt.org> wrote: > For what it's worth we did a similar thing, but > overrode RTDyldMemoryManager directly This allowed us

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

I have a function address held in an uint64_t. I would like to cast the function address to a function prototype and create a call to the function in LLVM. How could I do this ? Thanks Xin

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Xin Tong > Subject: [LLVMdev] Cast Pointer Address to Functions > I have a function address held in an uint64_t. I would like to cast > the function address to a function prototype and create a call to the > function in LLVM. How could I do this ? This is what works for us:

Hello, I am trying to create IR block for making a call to function pointer. For creating the IR for a function call to "foo", with "foo" being defined as "void foo(int)", I can use the "getOrInsertFunction" call from Module class as follows: std::vector<Type*> FooArgs; FooArgs.push_back(IRB.getInt64Ty()); Value *FooFunction =

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

Dear All I'm making an instrumentation pass. The pass is supposed to modify the given IR in a specefic way. One of the required modifications is to insert a call to a function at a specific location. This is the signature of the called function: void myclass::foo(Function *f, BasicBlock* b) This function's prototype is in an foofile.h file in include/llvm And the function

To create a stack based (local) 64 bit integer in LLVM IR, I used: Value *var = builder.CreateAlloca(Type::getInt64Ty(Ctx)); I wish to pass this variable to a function "void foo(unsigned long)". I created the signature of function foo() as follows: Constant *func = M->getOrInsertFunction("foo", Type::getVoidTy(Ctx),Type::getInt64Ty(Ctx), NULL); To pass the newly created

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

Hi, I am trying to write a simple interpreter. I am trying to generate LLVM IR for assignment operation. The code for the generation part looks like this llvm::Value* codeGenSymTab(llvm::LLVMContext& context) { > printf("\n CodeGen SymTab \n"); > Value *num = ConstantInt::get(Type::getInt64Ty(context), aTable.value, > true); > Value *alloc = new