similar to: [LLVMdev] MC-JIT

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

> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.

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

On 07/19/2010 05:14, Olivier Meurant wrote: > 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 >

New patch taking Eli's comments into account. Olivier. On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >>> Seems reasonable, but I haven't looked at the code yet. I would >>> suggest trying to split your work up into separate

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

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>

New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>

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

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

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

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

On Jun 24, 2011, at 12:44 PM, Yuri wrote: > On 07/19/2010 05:14, Olivier Meurant wrote: >> 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. >>

On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: >> Seems reasonable, but I haven't looked at the code yet. I would >> suggest trying to split your work up into separate patches which >> implement incremental pieces of functionality, then submitting them to >> llvm-commits for review. That is much easier for us to deal with

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

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]

On Mon, Jul 19, 2010 at 8:14 AM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > Attached you will find the patch introducing the first MCJIT draft. > Can you comment on this ? I can't get it to apply with either 'git apply' or patch. Something weird about the directory names. - Michael Spencer

I have cleaned up the code somewhat that Olivier wrote and split up the patch into three pieces. This first is to make the MCJIT not have to initialize all asm printers, but only the native one. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018_nativeasmprinterinit.patch Type: text/x-diff Size: 12993 bytes Desc: not available URL:

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