llvm-test warning

With a recent change made to the llvm-test makefiles, you may start getting failures for everything. To fix this, remove the 'native output' with a command like this:

find projects/llvm-test/ -name \*.out-nat -print -exec rm {} \;

The next time you run llvm-test, the native output will be rebuilt properly.

-Chris

All,

With a recent change made to the llvm-test makefiles, you may start
getting failures for everything. To fix this, remove the 'native output'
with a command like this:

find projects/llvm-test/ -name \*.out-nat -print -exec rm {} \;

FYI, the change made to llvm-test is to add an "exit <retval>" line at
the end of a program's output. This will ensure that any difference in
the program's return value (exit code) will be picked up by the
DiffOutput script and reported as a failure. The tests have all been
made "exit clean" (thanks Evan). The reason you need to remove
the .out-nat file is that they won't contain the "exit <retval>" line
until regenerated, while newly generated output for jit/llc/cbe will
contain "exit <retval>", which leads to false positives.

The next time you run llvm-test, the native output will be rebuilt
properly.

-Chris

Reid.

Hi,

As some of you may remember, I'm implementing an LLVM-based model checker. I'm doing something a little odd, in that mostly I'm using the interpreter (currently a hacked version of lli with threads) for most things because I need to hook into lots of stuff that would be difficult to manage otherwise, but I'm also using the jitter for some things that need to be fast and/or link with external code. I currently expose some functions from the code being checked that allow you to slot in your own thread management, but I need this to be as fast as possible because it gets called a *lot*. I have managed OK with simply exposing a function and jitting it, then calling it through the runFunction member of the Jitter class, which works fine but seems a little slow. How feasible would it be to get at the underlying function pointer directly, seeing as the type signature is well-known in advance, then just calling it with a normal C-style call to a function pointer, e.g. (*compfn)(a,b).

Yes, this is all a bit nuts, and yes, it's not really how either the interpreter or the jitter was meant to be used, but if I can make this particular trick work, it will significantly speed up the model checker, particularly since I'll be able to use it for a few other things too.

Thanks,
Sarah

Sarah Thompson wrote:

Hi,

As some of you may remember, I'm implementing an LLVM-based model checker. I'm doing something a little odd, in that mostly I'm using the interpreter (currently a hacked version of lli with threads) for most things because I need to hook into lots of stuff that would be difficult to manage otherwise, but I'm also using the jitter for some things that need to be fast and/or link with external code. I currently expose some functions from the code being checked that allow you to slot in your own thread management, but I need this to be as fast as possible because it gets called a *lot*. I have managed OK with simply exposing a function and jitting it, then calling it through the runFunction member of the Jitter class, which works fine but seems a little slow. How feasible would it be to get at the underlying function pointer directly, seeing as the type signature is well-known in advance, then just calling it with a normal C-style call to a function pointer, e.g. (*compfn)(a,b).

Yes, this is all a bit nuts, and yes, it's not really how either the interpreter or the jitter was meant to be used, but if I can make this particular trick work, it will significantly speed up the model checker, particularly since I'll be able to use it for a few other things too.

OK, I've answered my own question. What you need to do is export an initialisation function that returns a function pointer. You jit the initialisation function (by calling it), which also causes the address-taken function to be jitted. When you get the pointer back, *that* pointer can be called directly from C++, with no performance penalty. I think I'll be using this trick quite a bit.

Sarah

Sarah Thompson wrote:

Yes, this is all a bit nuts, and yes, it's not really how either the
interpreter or the jitter was meant to be used, but if I can make this

I welcome moderate insanity :slight_smile:

OK, I've answered my own question. What you need to do is export an
initialisation function that returns a function pointer. You jit the
initialisation function (by calling it), which also causes the
address-taken function to be jitted. When you get the pointer back,
*that* pointer can be called directly from C++, with no performance
penalty. I think I'll be using this trick quite a bit.

It should be easier than that: instead of calling runFunction, just call EE->getPointerToFunction and cast the return pointer to be the appropriate function pointer. getPointerToFunction will cause the function to be immediately compiled, and the function pointer is valid unless you explicitly release the code.

-Chris