Hi Viktor,<br><br><div class="gmail_quote">On Wed, Apr 6, 2011 at 4:47 PM, Viktor Pavlu <span dir="ltr"><<a href="mailto:vpavlu@gmail.com">vpavlu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thanks for all the replies!<br>
<br>
I wanted to closely resemble what the CACAO VM[1] backend did with<br>
success for a long time: for every CACAO IR instruction, there is a<br>
sequence of x86 instructions that get written directly to the executable<br>
memory. In CACAO, registers are used while available, then everything is<br>
spilled. Relocations are resolved and patched in a second go.<br></blockquote><div>Sounds good!<br><br>I think what we want here is something which is as generic as possible, e.g. it would be interesting to investigate whether it is possible to generate parameterizable chunks of machine code directly from LLVM IR instructions using the existing codegen infrastructure (at compile time of the LLVM JIT, like qemu does when invoking a C compiler on the C sources which implement the individual IR instructions). Leveraging as much as possible of the TableGen instruction descriptions and the MC infrastructure should also be an explicit goal.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<div class="im">> I'd be willing to mentor such a project, let me know if you're interested.<br>
<br>
</div>So yes, I would be interested.<br></blockquote><div>Awesome! <br><br>So I guess the next step is to come up with a detailed proposal and submit it :) <br></div><div> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Only recently is CACAO starting to get a register allocator to improve<br>
quality of the generated code.<br>
I wanted to include this in my first stab at the project but leaving<br>
register allocation for future work or even for the regular backend is<br>
fine with me, too.<br></blockquote><div>From my side you don't need to include a register allocator in the proposal. Leaving that open for future work is perfectly fine. Given the limited timeframe I'd see the main focus on JIT correctness/compile time rather than quality of the generated code.<br>
<br><br>Regards,<br><br>Tilmann<br></div></div>