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