On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote: > Hi all, > > Below is the proposal of this gSoc project. I'd really like you review and > comment on this and then I can plan this project better.
Hi Li, this looks nice. Thanks for your work on this. Tobias > > Thanks, > Li Feng > ---------------------------------------------------------------------------------------- > #title Automatic parallelization in Graphite > > * Synopsis > > With the integration of Graphite to GCC4.4, a strong loop nest > analysis and transformation engine was introduced. But now it > does only non-parallel loop generation. My work is to detect > synchronization free parallel loops and generate parallel code > for them, which will mainly enables programs to run faster. > [..] > * Road-map > > 1. Since data dependency analysis is not available, I will firstly > integrate autopar's code generation to Graphite. This work will > be done step by step.(Mid June) > - Introduce a flag -fgraphite-parallelize that forces auto-parallelization > for all loops. > - Make sure the loops Graphite creates can be handled by the autopar's > code generation. > - Call autopar for every loop.(The loops that can not be paralleled will > just fail/crash.) I think on this point we should discuss with Razya and the others where your work ends. Just adapting autopar to handle all graphite loops is a project on its own. So I do not think it can be done by you in two weeks. > 2. Write test cases for the loops that can be parallelized. This will take a > few discussions with Graphite developers to see which kind > of loops we will should detect and can be auto-parallelized.(End June) > 3. Write code for parallel code detection. This part of job will based on > SCoP detection and data dependency, and at this time, data dependency > analysis should have been done. This part of work will take most of > the time.(First week of August) How much time this point takes depends how exact you want to solve it. I think a correct but conservative implementation might be written in a week. If you want to detect all loops it will take you more time. > 4. Code cleaning and write documents.(Second week of August) I think it is useful to define the limits of your work a little bit stricter. For me there are two options: 1. You stay more on the autopar/gimple side (Step 1) and adapt autopar for graphite. This is very necessary for graphite, but it might need some time to get up to speed in autopar. 2. You stay more on the graphite/polyhedral side. You work on all these steps, but we limit step 1 to the graphite internal parts. This means you connect autopar to graphite and try to generate parallel loop nests. If autopar can not handle a loop nest you analyse it and write a bug report. Someone else will extend autopar. As Razya already has some knowlege about autopar and she is also interested in working on parallelization maybe she is able to support you with the autopar stuff? So you might be able to actually focus more on the polyhedral part. > * Profit for GCC > > - When the auto-parallelization has been done in Graphite, developer > can mostly take their effort to loop transformations. Graphite will be > in charge of optimizations(generate parallelism) and the autopar > code in Graphite will just detect and generate code for them. Tobias
