Escape the unnecessary re-optimization in automatic parallelization.

Escape the unnecessary re-optimization in automatic parallelization.

[Li Feng]

Hi,

I'm considering how to escape the unnecessary re-optimization
in automatic parallelization.

e.g.
in a source code the function fun() one loop
is considered can_be_parallel by Graphite pass, and in pass
tree-parloop.c, will call the code generation part for this loop and generate
newly created fun.loop_f0(), note that fun.loop_f0 is a function that has some
omp directive added on optimized function fun()'s loop (It has been optimized by
the passes before tree-parloop.c), and to my observation, the newly created
function fun.loop_f0 will be passed through the first pass again (Is this
statement corret?).

So my question is,

1. Is this necessary/correct if we want to escape the re-optimization for the
first few passes before tree-parloop.c and continue the optimization passes
after it for the function fun.loop_f0, there must be compile time savings if we
do this in my opinion.

2.
How could I do if we want to do this.

I'm not familiar with the mechanism that how passes works, it'll be
appriciate if someone can tell me more.

Thanks,
Li

Re: Escape the unnecessary re-optimization in automatic parallelization.

[Joern Rennecke]

Quoting Li Feng <nemokingdom@gmail.com>:
> So my question is,
>
> 1. Is this necessary/correct if we want to escape the re-optimization for the
> first few passes before tree-parloop.c and continue the optimization passes
> after it for the function fun.loop_f0, there must be compile time   
> savings if we
> do this in my opinion.

Note that the process of parallelization adds new code, and make  
pre-existing code makes code sub-optimal - e.g. it transforms the loop  
into a normal form
where there is only one induction variable.

So, even if you have a homogeneous sets of cores that you are targeting, it
makes sense in principle to re-start optimizations from the beginning.
If the re-running of each individual optimization pass makes sense will depend
on what that pass exactly does and how that relates to parallelized loop and
the target.

However, parallelization is done to differetn target architectures, then
re-running the optimization becomes more improtant, since different parameters
and heuristics can come into play.

Moreover, the set of optimization passes that run before parallelization is
subject to change as GCC evolves.

Therefore, the most effective way to address the issue of running redundant
optimization passes in the context is probably to put it in the wider context
of the work to allow external plugins to influence the pass sequence that is
being applied, and to control this with machine learning.

Re: Escape the unnecessary re-optimization in automatic parallelization.

[Li Feng]

Hi Joern,

On Sat, Oct 10, 2009 at 5:27 PM, Joern Rennecke
<joern.rennecke@embecosm.com> wrote:
> Quoting Li Feng <nemokingdom@gmail.com>:
>>
>> So my question is,
>>
>> 1. Is this necessary/correct if we want to escape the re-optimization for
>> the
>> first few passes before tree-parloop.c and continue the optimization
>> passes
>> after it for the function fun.loop_f0, there must be compile time  savings
>> if we
>> do this in my opinion.
>
> Note that the process of parallelization adds new code, and make
> pre-existing code makes code sub-optimal - e.g. it transforms the loop into
> a normal form
> where there is only one induction variable.
>
> So, even if you have a homogeneous sets of cores that you are targeting, it
> makes sense in principle to re-start optimizations from the beginning.
> If the re-running of each individual optimization pass makes sense will
> depend
> on what that pass exactly does and how that relates to parallelized loop and
> the target.
>
> However, parallelization is done to differetn target architectures, then
> re-running the optimization becomes more improtant, since different
> parameters
> and heuristics can come into play.

I agree that re-running will take difference parameters and heuristics come
into play.
But I'm not clear about re-running the first few passes will do
optimizations for
different target architectures for parallelization. shouldn't such
kind optimizations
be done at back-end ? I mean, since the first few passes before
autopar is in the
middle end.

>
> Moreover, the set of optimization passes that run before parallelization is
> subject to change as GCC evolves.
>

Yes. I agree.
> Therefore, the most effective way to address the issue of running redundant
> optimization passes in the context is probably to put it in the wider
> context
> of the work to allow external plugins to influence the pass sequence that is
> being applied, and to control this with machine learning.
>

Thanks,
Li

Re: Escape the unnecessary re-optimization in automatic parallelization.

[Yuri Kashnikoff]

> Therefore, the most effective way to address the issue of running redundant
> optimization passes in the context is probably to put it in the wider
> context
> of the work to allow external plugins to influence the pass sequence that is
> being applied, and to control this with machine learning.
>
Joern is right about external plugins. AFAIK, this work was done as a
part of GSoC#2009 project leaded by Grigori Fursin. Please check these
links for fufther information -
1) http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation#Work_with_adapt_plugin
2) http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Scripts

In my opinion, you can easily edit XML's generated by adapt plugin to
exclude particular passes, then run scripts to make adapt plugin
substitute passes according to your edited XML files.

Thanks!

Re: Escape the unnecessary re-optimization in automatic parallelization.

[Alexey Salmin]

Oh, hello Yuri, nice to meet you here :)

Alexey

On Tue, Oct 13, 2009 at 7:51 PM, Yuri Kashnikoff
<yuri.kashnikoff@gmail.com> wrote:
>> Therefore, the most effective way to address the issue of running redundant
>> optimization passes in the context is probably to put it in the wider
>> context
>> of the work to allow external plugins to influence the pass sequence that is
>> being applied, and to control this with machine learning.
>>
> Joern is right about external plugins. AFAIK, this work was done as a
> part of GSoC#2009 project leaded by Grigori Fursin. Please check these
> links for fufther information -
> 1) http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrumentation#Work_with_adapt_plugin
> 2) http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Scripts
>
> In my opinion, you can easily edit XML's generated by adapt plugin to
> exclude particular passes, then run scripts to make adapt plugin
> substitute passes according to your edited XML files.
>
> Thanks!
>