similar to: [LLVMdev] MC-JIT Design

Quick follow up here: I talked to Eric for a bit about this proposal, and he convinced me that we should take a slightly different tack. I'll write a bit more about it later. The idea Eric convinced me was better is to not invent a FOO format, but just use the native platform object format and focus on writing essentially a runtime linker for that platforms object files. This has various

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

What kind of restrictions will the existing object file formats impose on the JIT? I don't know enough about the JIT and object file format interaction to know if this will be an issue. It seems clear that it would be worse to try to encode "extra things" in some obscure way than to create the FOO format initially. If FOO is truly a superset of everything this could even be the

On Mon, 15 Nov 2010 11:34:22 -0800 Daniel Dunbar <daniel at zuster.org> wrote: > Quick follow up here: > > I talked to Eric for a bit about this proposal, and he convinced me > that we should take a slightly different tack. I'll write a bit more > about it later. > > The idea Eric convinced me was better is to not invent a FOO format, > but just use the native

On Tue, Nov 16, 2010 at 9:39 AM, James Molloy <James.Molloy at arm.com> wrote: > 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

As previous mentioned here, I think the best design would be to JIT code fast (using the FOO type) and then allow the user to build to some other format later if he/she wants. Reloading pre-JITed functions is a feature I'd like to see, because sometimes you have to JIT fast an inefficient function just to get it working and later optimize it. If you could save the functions for latter use

Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =

I was delayed creating the smaller patches, but finally I had some time to put the first set together. There are three small patches, the first two are classes the MCJITStreamer uses, and the last patch is the MCJITStreamer class itself. - Jan --- On Sun, 8/1/10, Daniel Dunbar <daniel at zuster.org> wrote: > From: Daniel Dunbar <daniel at zuster.org> > Subject: Re: [LLVMdev]

Some boring style comments: - whack trailing whitespace - spaces, not tabs - the methods in MCJITStreamer.cpp should probably have blank lines between them There seems to be an ownership problem of the MCJITObjectWriter. If I understand the code correctly, the assembler Finish method takes ownership of the Writer parameter, which presumably is needed to JIT two functions. +1 for separate

This patch contains the initial implementation of MCJIT. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019_mcjit.patch Type: text/x-diff Size: 42198 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100728/2eb6ac65/attachment.patch>

Hi Jan, I would rather not work with a patch this large. Can you pull out the addition of the MCJITStreamer into its own patch, and we can iterate on getting that in as a single commit? I realize it won't work or do anything useful, but I can't deal with reviewing patches this large. The main thing I am concerned about is getting the basic design of how the streamer and the assembler and

Hi LLVM folks, Attached with this email, you will find a patch not directly applicable (it doesn't compile like this) which (try to) enhance the structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer

Hi Chris, Thanks for taking time to communicate on this. In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? I assume, a MCJITStreamer is needed. And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? What

I do have an opinion, but don't have enough time to comment in much depth. The approximate approach I had in mind sounds like what you describe, though, the JITObjectWriter is the core piece, the other pieces probably fall into place as it becomes obvious if they are needed. It should be pretty straightforward to bring up something which works for running code with no external symbols, if you

Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thoughts and comments welcome, -Chris

On Fri, Nov 12, 2010 at 6:01 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > Will this poking include converting the JIT to use the MC framework? That is the motivation for me poking at things, yes. > I've added an MC based asm parser, disassembler, and code emitter recently to the MBlaze backend and it would be nice to get JIT support automatically :) I agree, that would be

On Apr 11, 2010, at 10:35 AM, Olivier Meurant wrote: > Hi Chris, > > Thanks for taking time to communicate on this. Sorry I missed responding to this email sooner. > In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? > > I assume, a MCJITStreamer is needed. > And

On Apr 9, 2010, at 23:32:12, Chris Lattner wrote: > Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thanks for the post, Chris. It

Hello, I'm part of a team at Intel that works on implementing the MC-JIT execution path for ELF objects with built-in support for debugging the JITted code with GDB. We currently have a working implementation passing all ExecutionEngine tests on MC-JIT for ELF, as well as several proprietary workloads. The current implementation focuses on Linux, although with some trivial modifications it

Hi ! > Sorry I missed responding to this email sooner. No problem, I was not in a hurry. :) > The approximate approach I had in mind sounds like what you describe, Ok Cool ! > I have been meaning to do this, but won't have time for a couple weeks I suspect. So I will give it a try. :) I was able to quickly hack a JITObjectWriter and I am able to execute simple functions (with