How is a Google Summer of Code in Graphite ?

During your Summer of Code you will be part of an international team working on Graphite. We meet once a week on the phone and stay the rest of the week in touch using the gcc-graphite mailing list. Once in a while we meet up at important conferences like the GCC Summit, the GROW workshop or have our own small meetings at INRIA or at AMD Austin/TX.

There have already been many successful summer of code students in Graphite. Tobias did the Summer of Code 2008 working on SCoP detection (Blog), Li Feng (Blog) worked in 2009 on automatic parallelization, Riyadh Baghdadi (page) worked in 2010 on adding SCoPLib support to Graphite (Page).

As a student you should know that working on GCC seems to be difficult, but it is not. Or at least not as difficult as you think. Just jump into the code - some well written, some a little ugly - related to your project and you will get all the support you need to be successful. The best way to find out if you could work on Graphite is to fix a small bug. We will glade to point you to a simple one and support you to get it fixed.

The following advices will help you prepare your Google summer of code proposal : 5 advices to get your Google Summer of Code proposal accepted.

Graphite Google Summer of Code ideas

Graphite has a long TODO list with open ideas. So we extracted some self contained project ideas for Summer of Code students. But you can also look at the open projects on the Graphite TODO list or propose your own idea

GCC has even more Summer of Code Projects in other areas of the Compiler.

Polyhedral transformations/optimizations in GRAPHITE (2010)

Beside the set of traditional loop transformations, which always work on loops, we might do optimizations in Graphite just by trying to get array accesses close by. These optimizations are a lot closer to the polyhedral model, as we do not think any more about loops but just statements and the point in time, when they are executed. So instead of applying some loop interchange to some loops, we just try to change the schedule of the statements in a way that accesses to the same array are as close as possible in time. The effect might be a normal loop interchange, but also some transformations that can not be expressed easily by traditional transformations.

This project is actually not well defined, as we only had some ideas. So you will jump in the darkness. But we hope there might be some interesting optimization opportunities for you.

Contact: Sebastian Pop, TobiasGrosser

TODO

Traditional loop transformations in GRAPHITE (2010)

There are a set of traditional loop transformations like interchange, strip-mining, blocking, fusion and splitting that compilers implement. Currently Graphite does a little blocking and interchange, but there are still some missing ones and for the implemented ones the heuristics have to be improved.

Contact: Sebastian Pop Info: Part of it is already implemented. Probably there is still enough to be done.

TODO

Improve Parallel code generation (2010)

Graphite can - thanks to Li - parallelize simple loops. It would be great to investigate the improvements because of this. Which loops can be parallelized? In which benchmarks are parallelization opportunities? And does Graphite parallelize them. Afterwords the runtime should be measured and improvements/regressions should be analyzed. During this analysis the basic implementation Li contributed should be improved such that at the end GCC is able to parallelize a reasonable number of Loops in well known benchmarks. This should be provable with numbers that either show Graphite does well, or that shows that more advanced algorithms are necessary to handle them, but graphite is able to extract these loops and could pass them e.g. to Pluto.

Contact: Sebastian Pop, TobiasGrosser

TODO

RelatedWorks

None: Graphite/SoC (last edited 2012-06-28 08:44:58 by TobiasGrosser)