search for: compfn

...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 to...

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

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/

...er 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 f...