search for: foojitstreamer

Displaying 4 results from an estimated 4 matches for "foojitstreamer".

2010 Nov 16
2
[LLVMdev] MC-JIT Design
...ation informations) 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,...
2010 Nov 16
0
[LLVMdev] MC-JIT Design
...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"...
2010 Nov 16
0
[LLVMdev] MC-JIT Design
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
2010 Nov 15
8
[LLVMdev] MC-JIT Design
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: --