On Sun, Apr 6, 2008 at 6:32 PM, John Criswell <<a href="mailto:criswell@uiuc.edu">criswell@uiuc.edu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">One of the things I noticed in the last message on llvm-qemu was that<br></div>
you were compiling with output from qemu with llvm-gcc?  Is this correct?</blockquote><div>Not really, llvm-gcc is only invoked once when llvm-qemu is being built.<br><br>Qemu's code generator works like this: a source machine instruction is decomposed into several simpler micro ops (basically the IR of qemu), for every micro op there is a C implementation, which at build time is compiled for the respective target architecture. At build time the actual code generator is generated by the tool dyngen, which parses the compiled micro op object file and generates a C function which receives a micro op stream and generates the corresponding machine code by concatenating the respective machine code for the micro ops and doing some additional patching (like inserting parameters for the micro ops). What I did for llvm-qemu is to write llvm-dyngen, which instead of an ELF file reads in a bitcode op.o (generated by compiling op.c with llvm-gcc) and creates a function which basically concatenates and patches the LLVM IR ops and after that JITs them. Every source architecture has different micro ops, thus llvm-dyngen needs to be used to create the code generator for a particular architecture.<br>
<br>Greetings,<br><br>Tilmann<br> </div></div><br>