similar to: [LLVMdev] Intro to the MC Project

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

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

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

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

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

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

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>

On Jan 10, 2013, at 22:10 , Sean Silva <silvas at purdue.edu> wrote: > On Thu, Jan 10, 2013 at 8:25 AM, Rick Mann <rmann at latencyzero.com> wrote: >> I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there: >> >>

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

On 27 Oct 2015, at 09:48, Senthil Kumar <senthil.thecoder at gmail.com> wrote: > > Haven't worked on this yet, but I work on the gcc AVR backend (and binutils), and I'm very interested in this - I intend to work on it in my spare time. And do you have any comments / objections to Dylan becoming the code owner? David

I've been writing up my experience embedding LLVM in a Cocoa app. If anyone would like to see it and give feedback, I'd appreciate it. It's still not finished, but the first part is there: http://roderickmann.org/stuff/LLVMTut/HowToEmbedLLVMWithXcode.html If it's worthy, hopefully it'll end up in the LLVM docs. -- Rick

On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > You need to include 'llvm/ExecutionEngine/JIT.h' (or 'llvm/ExecutionEngine/JIT.h' if you want that engine) from your main file. Including that file forces the JIT static constructor to be linked into your executable. Without it, the JIT static constructor gets optimized out and

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 =

Hi guys, attached are a couple of work in progress patches for ELF support in the MC module. I'm sending this email to gather some general feedback on the code. Applying these patches doesn't get you a fully working llvm-mc that understands ELF; it's just the ground work. I've got a couple more small patches that fixup some places that assume Mach-O object format which I'll

Hi Matt, Awesome! This is excellent progress, and it is great to see someone working on this. High level comments: (1) The order of patches is odd, to me. It would be great to start by adding the AsmParser support, then the MCStreamer support, so that we can have test cases in the 'llvm-mc cat' mode, where it just parses and prints out again. On 0001: - What is hasRelocationAddend? It

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

Exciting!!! > On Sep 29, 2015, at 17:03 , Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Dylan McKay via llvm-dev" <llvm-dev at lists.llvm.org> >> To: llvm-dev at lists.llvm.org, "David Siegel" <agnat at me.com> >> Sent: Thursday, September 3, 2015 10:35:16 PM >>