[LLVMdev] Intro to the MC Project

[Olivier Meurant]

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



On Fri, Apr 16, 2010 at 10:58 PM, Daniel Dunbar <daniel_dunbar at apple.com>wrote:

> 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
>
> On Apr 15, 2010, at 1:40 PM, Chris Lattner wrote:
>
> >
> > 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100417/02e4346a/attachment.html>