Re: {gSoc}application : Automatic parallelization in Graphite

[Razya Ladelsky <RAZYA at il dot ibm dot com>]

Tobias Grosser <grosser@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
>