Re: [RFC] [parloop branch] Supporting reductions for automatic parallelization

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

Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote on 17/08/2007 18:13:36:

> 
> > --- 3696,3717 ----
> >      {
> >        /* Otherwise, this directive becomes the parent for a new
> >           region.  */
> > !           if (code == OMP_ATOMIC)
> > !             {
> > !          region = new_omp_region (bb, code, parent);
> > !          region->exit = bb;
> > !        }
> > !           else
> > !        {
> > !          region = new_omp_region (bb, code, parent);
> > !          parent = region;
> > !        } 
> >      }
> >       }
> > ! 
> >     if (single_tree && !parent)
> >       return;
> > ! 
> >     for (son = first_dom_son (CDI_DOMINATORS, bb);
> >          son;
> >          son = next_dom_son (CDI_DOMINATORS, son))
> 
> This piece does not seem to be necessary.

I'm not sure which part you meant.
Did you mean that this whole part of marking OMP_ATOMIC as a new region is 
unnecessary?

> 
> > +      new_reduction->reduction_var = SSA_NAME_VAR (PHI_RESULT (phi));
> 
> Using SSA_NAME_VAR for anything is definitely wrong -- the ssa names
> involved in the reduction pattern do not have to have the same
> SSA_NAME_VAR, ...
> 

I'm a little confused...

If I understand correctly, the scalar variable is what defines the 
reduction
and therefore I'm looking  for all uses/defs of the same reduction 
variable, what 
other way is there to do so?

Currently I am dealing only with simple reduction patterns, that 
are identified by vect_is_simple_reduction, which is looking for
the reduction in a (single block)loop in the following way:

L0:
x_i = phi (x_j, x_k)
...

x_g = x_i + something
(goto L0)

Where the "+" represents a reduction operation.

More complicated patterns are not identified at the moment, and hopefully 
can be reduced to this form for easier handling.

Is my conception wrong?

> > !      if (reduction_list)
> > !        {
> > !          tmpred.reduction_var = SSA_NAME_VAR (PHI_RESULT (phi));
> > !          red = htab_find (reduction_list, &tmpred);
> > !          if (red == NULL)
> > !       return false;
> > !          else
> > !       red->reduc_phi = phi;
> 
> ... and ssa names with the same SSA_NAME_VAR can be completely
> unrelated.

But if they're in the header of the loop I'm looking at, and they are
related to the reduction variable, they are related, no?


> Ditto.  Thanks for your effort.  Could you please send me the updated
> patch once you have it?  I did not go through the rest of the patch yet
> (I will do it once you add the comments explaining what transformation
> you perform and what do the fields of struct reduction_info mean).
> 

Thanks for your quick review and help,
I'll add comments and resend the patch,
Razya


> Zdenek