similar to: [LLVMdev] llvm-mc and JIT

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]

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

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:

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 =

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 >

Hi Jan, Applied with edits in r109996, thanks! I wasn't happy about the change to add "Target" everywhere -- I just added a local hack in TargetSelect.h to workaround this. We should really change the definition of LLVM_NATIVE_TARGET, but I am not in a configure hacking mood. - Daniel On Wed, Jul 28, 2010 at 10:39 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > I have

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

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

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

----- Original Message ---- > From: Chris Lattner <clattner at apple.com> > To: Yuri <yuri at rawbw.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Sun, February 20, 2011 3:26:35 AM > Subject: Re: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule > > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >>

On Feb 24, 2011, at 4:05 AM, Jan Sjodin wrote: > On Feb 19, 2011, at 8:05 PM, Yuri wrote: >> >>> On 02/19/2011 14:52, Yuri wrote: >>>> Will MC path for JNI be included in 2.9? >>>> >>> >>> Sorry. I meant: Will MC path for JIT be included in 2.9? >> >> While it would be nice, it doesn't seem like anyone is working on

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

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

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

Hello. We found the following problem with MC JIT, on ARM it can't generate valid code for instruction "bl <external_function>" like: bl printf Because the ELF file in memory generated by MC JIT does not have the .plt section, but we need to have the following code to be emitted in it: .plt:00008290 STR LR, [SP,#-4]! .plt:00008294

Hi, Duncan > it is not in llvm-2.8, it will not even be in llvm-2.9. This is why you > couldn't find it :) Some patches went into the subversion repository > lately if you are interested. You mentioned "the plan was to solve this with the new MC-JIT". You mean that MC-JIT can handle inline assembly as an input, and generate target binary code? Regards, chenwj --

Hi chenwj, >> support any inline assembler on any platform, and that the plan was to >> solve this with the new MC-JIT, see >> http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html > > At the first glance, I think what llvm-mc does is, given an input, > llvm-mc will disassemble the input into assembly. I don't know the > MC-JIT you mentioned can be

Hi, Duncan > support any inline assembler on any platform, and that the plan was to > solve this with the new MC-JIT, see > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html At the first glance, I think what llvm-mc does is, given an input, llvm-mc will disassemble the input into assembly. I don't know the MC-JIT you mentioned can be used as a JIT. Currently, a JIT is

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