search for: mcjitstream

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] MC-JIT Patches 2/3 > To: "Jan Sjodin" <jan_sjodin at yahoo....

I cleaned up the indentation in the three patches and attached them. Please let me know if there are other issues. The patches should all apply cleanly with the latest revision. I will wait with submitting more patches until the MCJITSTreamer has been reviewed and checked in. Thanks, Jan --- On Sat, 8/21/10, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: From: Bruno Cardoso Lopes <bruno.cardoso at gmail.com> Subject: Re: [LLVMdev] MC-JIT Streamer 1/3 To: "Jan Sjodin" <jan_sjodin at yahoo.com> C...

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 the ob...

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 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 would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be...

..., 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 want to start this, I would recommend just trying to write the JITObjectWriter (and matching MCJITStreamer), and see where it goes. You can clone most of the Mach-O streamer for use by the JITStreamer, and gut the obviously unneeded parts. Once we have something working, we can factor out a common MCObjectStreamer class. I have been meaning to do this, but won't have time for a couple weeks I susp...

...able (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 - a PassManager for scheduling of an AsmPrinter (MCLowering) using the streamer - MCJITStreamer - owns and creates : - a MCAssember - a MCJITObjectWriter - a mem_raw_ostream - knows : - the MCJIT : to give it to the object writer (for mapping) - the MemoryManager : to...

...ris, > > 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 probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? > > What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the Asm...

...gt; 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 want to start this, I would > recommend just trying to write the JITObjectWriter (and matching > MCJITStreamer), and see where it goes. You can clone most of the Mach-O > streamer for use by the JITStreamer, and gut the obviously unneeded parts. > Once we have something working, we can factor out a common MCObjectStreamer > class. I have been meaning to do this, but won't have time for a coup...

...ith the optional flag "-mcjit". The MCJIT can now execute little functions with no relocation (like add(a,b) => a+b), to do that some modifications have been made : - The addPassesToEmitMC method has been added to TargetMachine class. It fills the MCContext pointer so we can build the MCJITStreamer. - The Finish method of MCAssembler have a new optional argument "Writer" to allow a custom MCJITObjectWriter to be used. Can you give us some feedbacks on the general idea and on this 2 particular hooks ? Currently MCJIT has one unittest and the binary size is quite big (~110MB in d...

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 patches,...

...! I finally found the "InitializeNativeTarget" method which do what I need. Olivier. On Tue, Jul 20, 2010 at 7:06 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > 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. &g...

...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: -- #1 (aka MCJIT) - We make a new MCJITStreamer which communicates with the JIT engine to arrange to plop code in the right place and update various state information. This is the most obvious approach, is roughly similar to the way the existing JIT works, and this is the way the proposed MC-JIT patches work (see MCJITState object). It also...

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

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

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

...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: > > -- > > #1 (aka MCJIT) - We make a new MCJITStreamer which communicates with > the JIT engine to arrange to plop code in the right place and update > various state information. > > This is the most obvious approach, is roughly similar to the way the > existing JIT works, and this is the way the proposed MC-JIT patches > work (see...

...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: > > -- > > #1 (aka MCJIT) - We make a new MCJITStreamer which communicates with > the JIT engine to arrange to plop code in the right place and update > various state information. > > This is the most obvious approach, is roughly similar to the way the > existing JIT works, and this is the way the proposed MC-JIT patches > work (see...

...ow, 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: > > > > -- > > > > #1 (aka MCJIT) - We make a new MCJITStreamer which communicates with > > the JIT engine to arrange to plop code in the right place and update > > various state information. > > > > This is the most obvious approach, is roughly similar to the way the > > existing JIT works, and this is the way the proposed MC-JI...

...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: > > > > -- > > > > #1 (aka MCJIT) - We make a new MCJITStreamer which communicates with > > the JIT engine to arrange to plop code in the right place and update > > various state information. > > > > This is the most obvious approach, is roughly similar to the way the > > existing JIT works, and this is the way the proposed M...