Hi !<br><br>> Sorry I missed responding to this email sooner.<br><br>No problem, I was not in a hurry. :)<br><br><br>> The approximate approach I had in mind sounds like what you describe,<br><br>Ok Cool ! <br><br>> I have been meaning to do this, but won't have time for a couple weeks I suspect.<br>
<br>So I will give it a try. :)<br><br>I was able to quickly hack a JITObjectWriter and I am able to execute simple functions (with no relocation in it).<br><br>I'm hitting some designs questions and before going in relocations, I think, it's good to discuss them :<br>
<br>- 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.<br>
To discriminate, I see 2 possibilities :<br>- Add an argument to createAsmBackend functions (bool IsJIT ?)<br>- 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.<br>
What do you think ? Do you see another possibilities ?<br><br><br>- 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 :<br>
if (Triple(TargetTriple).getEnvironmentName().equals("JIT")) {<br> AsmStreamer.reset(createJITStreamer(*Context, *TAB, Out, MCE));<br> } else {<br> AsmStreamer.reset(createMachOStreamer(*Context, *TAB, Out, MCE));<br>
}<br>What do you think ? Do you consider this to be acceptable ? Or just horrible ?<br><br><br>- MCObjectWriter::Write8 and MCObjectWriter::WriteBytes are designed to write in a raw_ostream instance, to adapt them to the JIT, I see 2 possibilities :<br>
- 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.<br> - Make a JIT_raw_ostream (or a memory_raw_ostream) class (inherits from raw_ostream).<br>
What do you think ?<br><br><br>Olivier.<br><br><br><br><div class="gmail_quote">On Fri, Apr 16, 2010 at 10:58 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel_dunbar@apple.com">daniel_dunbar@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
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.<br>
<font color="#888888"><br>
- Daniel<br>
</font><div><div></div><div class="h5"><br>
On Apr 15, 2010, at 1:40 PM, Chris Lattner wrote:<br>
<br>
><br>
> On Apr 11, 2010, at 10:35 AM, Olivier Meurant wrote:<br>
><br>
>> Hi Chris,<br>
>><br>
>> Thanks for taking time to communicate on this.<br>
><br>
> Sorry I missed responding to this email sooner.<br>
><br>
>> 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" ?<br>
>><br>
>> I assume, a MCJITStreamer is needed.<br>
>> And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ?<br>
>><br>
>> What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ?<br>
><br>
> 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.<br>
><br>
>> What was on your mind on this subject ? Anyone has already begin to work on this ?<br>
><br>
> No one is working on it! It would be great for this to start,<br>
><br>
> -Chris<br>
<br>
</div></div></blockquote></div><br>