Re: {gSoc}application : Automatic parallelization in Graphite

[Li Feng <nemokingdom at gmail dot com>]

Hi Tobi,

On Thu, Mar 26, 2009 at 3:17 PM, Tobias Grosser
<grosser@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