search for: foojitobjectwrit

...) or in file (with relocation informations). This allow to reload code from previous run, or even to have a powerful server preparing code and clients executing code. This not really tied to first or second proposition. And even for creating a "FOOJIT" format, you need a FOOJITStreamer, a FOOJITObjectWriter and probably a raw_ostream interface to write in memory. Seems really similar to the first set of patchs to me. What need to be done : - We need to define a FOOJIT format. Maybe we can focus on having a FOOJIT format only for "fast path" now, and adding relocations, symbols later ? - W...

...ith relocation informations). This allow to reload code from previous run, > or even to have a powerful server preparing code and clients executing code. > This not really tied to first or second proposition. And even for creating a > "FOOJIT" format, you need a FOOJITStreamer, a FOOJITObjectWriter and > probably a raw_ostream interface to write in memory. Seems really similar to > the first set of patchs to me. > > What need to be done : > - We need to define a FOOJIT format. Maybe we can focus on having a FOOJIT > format only for "fast path" now, and adding rel...

Hi, I've been watching the MC-JIT progress for some time, and #2 certainly looks like the best idea to me. I think however you've missed an important selling point of the "FOOJIT" architecture: * The use of a custom object file format directly enables the use of ahead-of-time compilation (using the JIT to recompile dynamically). Not only this but it allows the resaving of any

Hi all, As promised, here is the rough design of the upcoming MC-JIT*. Feedback appreciated! (*) To be clear, we are only calling it the MC-JIT until we have finished killing the old one. When I say JIT below, I mean the MC-JIT. I basically am ignoring completely the existing JIT. I will keep things API compatible whenever possible, of course. I see two main design directions for the JIT: --