Intro to the MC Project

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

Thanks for the post, Chris. It definitely helped to fill in some gaps in what I've learned so far, and I wasn't aware of the blog before. It's good to read some documentation that I know is current!

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

What was on your mind on this subject ? Anyone has already begin to work on this ?

Olivier.

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

I'm not sure the best path forward on this, Daniel may have an opinion. The two options are to implement a new mcstreamer, or to implement a new ".o file" in the assembler backend. Of the two, I would think the later option is best, but I'm not really sure what it would entail.

What was on your mind on this subject ? Anyone has already begin to work on this ?

No one is working on it! It would be great for this to start,

-Chris

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

- Daniel

Hi !

Sorry I missed responding to this email sooner.

No problem, I was not in a hurry. :slight_smile:

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

I was able to quickly hack a JITObjectWriter and I am able to execute simple functions (with no relocation in it).

I’m hitting some designs questions and before going in relocations, I think, it’s good to discuss them :

  • I have created a JITX86AsmBackend which creates the JITObjectWriter. The function which is registered to create AsmBackend (createX86_32/64AsmBackend) needs to know if it should create a classical (ELF, or Darwin/Macho) AsmBackend or a JIT one.
    To discriminate, I see 2 possibilities :

  • Add an argument to createAsmBackend functions (bool IsJIT ?)

  • Set something specific to the JIT on the target triple. Currently I have a “JIT” string in the environment part of the triple. (i686-pc-linux-gnu becomes i686-pc-linux-JIT). As the target triple is easy to change, this is currently the solution I use.
    What do you think ? Do you see another possibilities ?

  • Currently I’m using the LLVMTargetMachine::addPassesToEmitFile with FileType set to CGFT_ObjectFile, and with the triple environment name hack, I am able to create the correct streamer :
    if (Triple(TargetTriple).getEnvironmentName().equals(“JIT”)) {
    AsmStreamer.reset(createJITStreamer(*Context, *TAB, Out, MCE));
    } else {
    AsmStreamer.reset(createMachOStreamer(*Context, *TAB, Out, MCE));
    }
    What do you think ? Do you consider this to be acceptable ? Or just horrible ?

  • MCObjectWriter::Write8 and MCObjectWriter::WriteBytes are designed to write in a raw_ostream instance, to adapt them to the JIT, I see 2 possibilities :

  • Add a virtual keyword on Write8/WriteBytes and re-implement them in JITObjectWriter ? This is my current solution but I fear it’s not so good for the performances.

  • Make a JIT_raw_ostream (or a memory_raw_ostream) class (inherits from raw_ostream).
    What do you think ?

Olivier.

Hi !

Forget This email, I think I have a cleaner solution. I will come back with a patch, it will ease the discussion. :slight_smile:

Olivier.