Hi Tobi, On Thu, Mar 26, 2009 at 3:17 PM, Tobias Grosser <gros...@fim.uni-passau.de> wrote: > 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.
It's good that Razya do the autopar related job, then I can focus mostly on the polyhedral part. So I think my work will be: 1. detect loops that can be parallel(based on SCoP detection and data dependency test). 2. connect Graphite with autopar part(by Razya) And thanks for your comment :) >> * 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 > > Li Feng
