[LLVMdev] Google SoC Proposal Draft

[Reid Spencer]

Hi Tilmman,

Thanks for submitting this. Here's some feedback.

On Sun, 2007-03-25 at 00:41 +0100, Tilmann Scheller wrote:
> Hello,
> 
> here's my proposal for a GSoC project with LLVM. I'm happy for any 
> feedback or advice you can give me.
> 
> Thanks in Advance
> 
> Tilmann
> 
> 
> * Proposal for Google Summer of Code Project
> 
> ** Using LLVM as a backend for QEMU's dynamic binary translation
> 
> 
> *** Abstract:
> The goal of this project is to modify the QEMU dynamic binary translator 
> to use components of the LLVM compiler infrastructure to turn it into a 
> highly optimizing dynamic binary translator in order to increase the 
> performance of QEMU even further. Instead of directly emitting code for 
> the host architecture QEMU is running on, the target code is first 
> translated to LLVM IR, then a selection of LLVM's optimization functions 
> is applied to the IR and as a last step the LLVM JIT is used to generate 
> code from the optimized IR for the host architecture. Detailed speed 
> measurements will be performed in order to evaluate the efficiency of 
> this approach, especially in comparison to the approach currently used 
> by QEMU.

One thing I find lacking here is any mention of how you'll address the
extra time taken generate, optimize and code gen with LLVM. If I
understand QEMU, it translates to an intermediate representation and
then (fairly directly) executes on the native machine. I assume you will
translate this intermediate representation to LLVM IR, run passes, and
then JIT. You probably only want to do that if you know the function is
going to be called a lot or it has loops, etc. The cost of a second
layer of representation (LLVM IR), optimization and code generation is
non trivial and could easily dwarf the execution time of the
functions/programs involved. Do you have a strategy for addressing this?

> 
> 
> *** Benefits:
> QEMU will largely benefit from this project through an expected increase 
> in speed, while remaining portable.
> Through this project LLVM will effectively get frontends for all target 
frontends -> front ends
> architectures supported by QEMU (at the moment this are x86, ARM, SPARC, 
> PowerPC and MIPS). 
this -> these

I'm not sure how strong a point this is. The only processor there that
LLVM lacks is MIPS so we can always test on the native hardware. A MIPS
BE has been proposed as well.

> This offers many opportunities and new fields for the 
> application of LLVM on binary code e.g. optimization of binaries where 
> no source code is available. 

The main advantage I see here is that QEMU would allow us to *test*
binaries for multiple targets (those supported by QEMU) without the need
for that target's hardware. While that's an advantage, I don't think its
a "new field". 

What other "opportunities and new fields" do you see for this? If I were
Google, I wouldn't find the argument that it "allows cross-target
testing for LLVM JIT" very compelling.

> Also since the LLVM JIT will be used for 
> the final code generation QEMU can be hosted on any architecture 
> targetted by the LLVM JIT (at the moment this are x86, x86-64, PowerPC 
targetted -> targeted

> and PowerPC 64), at least concerning code generation. Further 
> adjustments to QEMU might be necessary though to get QEMU to run on a 
> certain architecture which is supported by the LLVM JIT but not by QEMU. 
> This project will show the applicability of LLVM in an emulation 
> environment, especially in regard to dynamic binary translation. It can 
> also be used as a basis to try out concepts like profile-guided 
> optimization or static optimization in the context of an emulator.
> 
> 
> *** Deliverables:
> - a version of QEMU with an optimizing dynamic binary translator 
> utilizing LLVM components
> - a set of test suites which are created during the development

You might want to hint at the level of coverage you can reasonably do in
the time frame you have. 

> - all necessary documentation to understand and be able to maintain the 
> software
> 
> 
> *** Plan:
> The development of the software will be done within the three month 
> timeframe of GSoC. Weekly status reports will be given.
> 
> Week 1, 2:
>       - get familiar with LLVM and QEMU
>       - write small test programs for certain LLVM components, or even a 
> simple prototype
>       - get to know LLVM example programs
> Week 3, 4:
>       - modify QEMU's dynamic binary translator to emit LLVM IR
>       - create tests to verify the translation
I think this is going to take longer than 2 weeks, but that's just my
guess.
> Week 5, 6:
>       - integrate LLVM JIT into QEMU's dynamic binary translator
>       - perform first speed measurements
> Week 7, 8:
>       - integrate LLVM optimizations into QEMU
>       - perform more speed measurements, select useful optimizations
> Week 9, 10:
>       - test the system extensively
>       - write final documentation
> Week 11, 12:
>       - time buffer to deal with unexpected events
> 
> 
> *** Qualification:
> I'm a graduate student studying Software Engineering at the University 
> of Stuttgart in Germany. I have a strong interest in compiler technology 
> and see this project as a great opportunity to gain experience in this 
> field. I have taken a compiler building class and plan to focus my 
> future studies in this area.
> Emulation is another area I'm interested in. I wrote a Game Boy Advance 
> emulator in C from scratch and a GP32 emulator based on QEMU (also C). 
> While doing this I gained a basic understanding of the QEMU codebase.

How much more familiar do you need to get? This is somewhat
contradictory with spending 1-2 weeks learning LLVM/QEMU that you have
in the Plan.

> I'm currently involved in a university project which develops a testing 
> tool for glass box tests for Java and COBOL, which allows to gather 
> certain coverage metrics, and which will be opensourced later this year.
> I have decent experience with C and Java and i'm familiar with C++. Also 
> I have a deep understanding of the ARM architecture and I'm familiar 
> with x86.
> This project is a big chance for me to give something back to the open 
> source community, especially since both LLVM and QEMU can profit from 
> this project.

Yup, I'm sure both projects will welcome it.

Sounds like an interesting project. Hope you get it.

Reid.

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev