llvm dev - Nov 2006 - [LLVMdev] 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

-- 
http://nondot.org/sabre/
http://llvm.org/

All,

On Wed, 2006-11-29 at 11:04 -0800, Chris Lattner wrote:
> 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