[LLVMdev] GSoC 2011: Fast JIT Code Generation for x86-64

Tilmann Scheller tilmann.scheller at googlemail.com
Wed Apr 6 14:26:13 PDT 2011


Hi Viktor,

On Wed, Apr 6, 2011 at 4:47 PM, Viktor Pavlu <vpavlu at gmail.com> wrote:

> Thanks for all the replies!
>
> I wanted to closely resemble what the CACAO VM[1] backend did with
> success for a long time: for every CACAO IR instruction, there is a
> sequence of x86 instructions that get written directly to the executable
> memory. In CACAO, registers are used while available, then everything is
> spilled. Relocations are resolved and patched in a second go.
>
Sounds good!

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.


>
> > I'd be willing to mentor such a project, let me know if you're
> interested.
>
> So yes, I would be interested.
>
Awesome!

So I guess the next step is to come up with a detailed proposal and submit
it :)


> Only recently is CACAO starting to get a register allocator to improve
> quality of the generated code.
> I wanted to include this in my first stab at the project but leaving
> register allocation for future work or even for the regular backend is
> fine with me, too.
>
>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.


Regards,

Tilmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110406/6842b7f3/attachment.html>


More information about the llvm-dev mailing list