search for: llvm_make_modul

...t; If kept simple, standardized, and generic, I think it would be very useful > to people (even if incomplete). This would allow others to build on it, > and we could 'ship' it as a standard llvm library. It looks like my interface will look vaguely like this. Functions like "llvm_make_module" will take in text representations of the module. This seems to be the fastest way of getting our scheme implementation to talk to the jit. This requires being able to parse strings. The LLVM 'Parser.h' interface (and implementation) has the built in assumptions that it will always b...

On Thu, 5 May 2005, Alexander Friedman wrote: >>> Does there happen to be a C interface to the jit ? Our scheme impl >>> has a good FFI, but it doesn't do C++. If not, this is no big deal, >>> and i'll just write something myself. >> >> No, but such bindings would be *very useful*. And since there might be >> other people who need them this

...tandardized, and generic, I think it would be very useful >> to people (even if incomplete). This would allow others to build on it, >> and we could 'ship' it as a standard llvm library. > > It looks like my interface will look vaguely like this. Functions like > "llvm_make_module" will take in text representations of the > module. This seems to be the fastest way of getting our scheme > implementation to talk to the jit. ok > This requires being able to parse strings. The LLVM 'Parser.h' interface > (and implementation) has the built in assumpti...

> So as it stands, one should think of out JIT as something akin to the > early Java JITs: one function at a time and only one compile per > function. This is extremely primative by modern JIT standards, where a > JIT will do profiling, find hot functions and reoptimize them, > reoptimize functions when more information about the call tree is > available, have several levels of