similar to: [LLVMdev] jit with external functions

On Fri, 8 Dec 2006, Ram Bhamidipaty wrote: > Can I place references to external functions in the assembler files? For example > I if my application has a function called fred() I would like to place > calls to fred > in the assembler text file. Can I do that and have the external function call > resolve to the address of fred() in my application? Yes, you can do this. The JIT will

On 12/8/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 8 Dec 2006, Ram Bhamidipaty wrote: > > Can I place references to external functions in the assembler files? For example > > I if my application has a function called fred() I would like to place > > calls to fred > > in the assembler text file. Can I do that and have the external function call >

On Sat, 9 Dec 2006, Ram Bhamidipaty wrote: > Will it also handle symbols that are in shared libraries loaded into > the process? I'm not sure, but I thought so. > I am creating a python module that has the llvm functionality. This > module is loaded > into the process as a shared library. I want to generate llvm assembler that has > calls to functions in this shared

Hi Jan, In gcc for Linux, you have the -rdynamic option that allows an executable to dlsym its symbols. Since llvm use dlsym to find the symbols, you could try with this option. That's what I did. And don't forget to use the C++ name if you compile with C++. Cheers, Nicolas Jan Rehders wrote: > Hi, > > I was able to try this on linux again. Unfortunately it doesn't work

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

I have an external function that was added with ExecutionEngine::addGlobalMapping... and the JIT is burning the wrong address into the emitted function. All of the addresses have 0xffffff8d00000000 added to them. Does this look familiar to anyone? I'm using 2.6 on Solaris10/x64 if it matters. This has been working for about two months and I can't readily figure out what I changed to break

I had that problem too: http://llvm.org/bugs/show_bug.cgi?id=5116. To work around the problem, you can: * Switch to the thread-unsafe lazy jit. * Allocate your JIT code within 2GB of your text segment. * Find a way to look up the external function with dlsym or maybe the ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping. * Upgrade to the top of the svn tree. On Mon, Dec 7,

Hi Gabi, I have no idea why your performances is not as expected with such low level of informations. But, I know that the binary code is cached by the JIT. You can find the code in JIT.cpp to convince yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each

Hi, > Okay. If the function exists in your application's address space > already, > just name the LLVM function the same name as the native function > and the > JIT should find it an do the right thing. This is how it finds > printf and > a variety of other things. You don't need to call addGlobalMapping at > all. Looking at the output of "nm

Hi, > If I recall correctly, in Linux you get the message: > > PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' > > > Right? But on OS X you don't have this messsage? Not exactly. There seem to be two problems. Your patch fixes one of them: in OS X I

Probably because the integer version of the prototype is special-cased. The problem is that the JIT has a C function pointer of an arbitrary type that it only finds out about at runtime. Normally, if you call a function pointer with a known type, your compiler will generate the proper calling code and allocate the arguments in registers or on the stack. However, doing that inside the JIT would

Hi Jan, If I recall correctly, in Linux you get the message: PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' Right? But on OS X you don't have this messsage? Here's a temporary fix until I find time to investigate on this: In function PPCISelLowering::LowerCALL,

Hi, I am having some difficulties getting the LLVM JIT to resolve extern "C" functions which I have defined in source file and invoking them via EE::runFunction() after generating a Function prototype for it. Is this possible or do I need to generate a .so for my functions are link against it? Thanks in advanced, Carter. Sorry for the double post but apparently I mistakenly tagged

Hi, I am having some difficulties getting the LLVM JIT to resolve extern "C" functions which I have defined in source file and invoking them via EE::runFunction() after generating a Function prototype for it. Is this possible or do I need to generate a .so for my functions are link against it? Thanks in advanced, Carter. Sorry for the double post but apparently I mistakenly tagged

Hi, attached is a small testcase I did. It builds two LLVM functions which both call two native functions get5 and get6. The native functions are in the exe and in the dll. On OS X it works like a charm. On Linux none of the two functions can be called. Maybe someone can try them or have a look at it to see if there is something obviously wrong greetings, Jan -------------- next part

On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: > I am having some difficulties getting the LLVM JIT to resolve extern > "C" functions which I have defined in source file and invoking them > via EE::runFunction() after generating a Function prototype for it. > Is this possible or do I need to generate a .so for my functions are > link against it? If the JIT needs

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

I am trying to understand the hello word assember example. This is my version: %str1 = internal constant [13 x sbyte] c"Hello World\0a\00" declare int %printf(sbyte*, ...) implementation ; Functions: int %main() { %str2 = getelementptr [13 x sbyte]* %str1, long 0, long 0 call int(sbyte*, ...) *%printf(sbyte* %str2) ret int 0 } Why is getelementptr being given two "long

Reid, Thanks! You were right! Changing the code to: float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); float retVal = theF(arg1); made the difference. Now it is dozens of times faster! I don't really understand the cause though.. Why doesn't ExecutionEngine cope well with "define float @someFunc(float %x)" and needs this trick ? (but copes well with

Hello, can anyone help me calling native functions from LLVM-Bytecode functions run in the JIT? I have a program which creates an LLVM execution engine and adds modules and functions to it on the fly. I need to call some native functions of my program from bytecode functions which causes some troubles as it appears not to be documented. My test scenario works like the following: I have