Tobias Grosser <gros...@fim.uni-passau.de> wrote on 26/03/2009 09:17:26:
> 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. I think this sounds like a good plan for the parallel code generation part (phase 1) Li will focus more on the Graphite side and I will contribute on the gimple side. Razya > > > * 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 >
