[LLVMdev] Intro to the MC Project

[Olivier Meurant]

Hi !

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

Olivier.

On Sat, Apr 17, 2010 at 2:37 AM, Olivier Meurant
<meurant.olivier at gmail.com>wrote:

> 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/20100418/bbf1423e/attachment.html>