[patch] Autoparallelization

Zdenek Dvorak rakdver@kam.mff.cuni.cz
Thu Sep 13 19:00:00 GMT 2007


Hello,

> >+ /* Parallelization.  */
> >+
> >+ static bool
> >+ gate_tree_parallelize_loops (void)
> >
> 
> >+ static unsigned
> >+ tree_parallelize_loops (void)
> >
> 
> >+ struct tree_opt_pass pass_parallelize_loops =
> 
> Why not declare these three in tree-parloops.c?  Not that it matters  
> much, just curious.

from some reason I have already forgotten, long time ago, I put all the pass
structures for loop optimization passes to tree-ssa-loop.c.  Now I just
keep them there... I guess this should be changed.

> >+ 	{
> >+ 	  if (dump_file && (dump_flags & TDF_DETAILS))
> >+ 	    fprintf (dump_file, "  FAILED: non-biv phi node\n");
> 
> Hmm, these messages are typically read by users who are looking to  
> parallelize their code.  The phrase 'non-biv phi node' will be  
> perplexing to anyone not thoroughly familiar with compiler lingo.

Well, I think that these messages are typically read by someone hunting
for a bug (frankly -- no user without a thorough knowledge of gcc
internals can interpret any of -fdump-tree-all-details dumps).

I will try to make the message more explanatory, though.

> >+       /* We should mark *arg_struct call clobbered.  However,  
> >this means
> >+ 	 we would need to update virtual operands for every function call.
> >+ 	 To avoid this, we pretend this variable is volatile.  */
> >+       TREE_THIS_VOLATILE (*arg_struct) = 1;
> >
> Hmm, OK I guess.  Not too happy about this, but I understand why  
> you'd want to do this.

Actually, thinking about it again, we should probably rerun alias
analysis here anyway, as otherwise we might lose virtual operands
for non-gimple_reg variables that were not call clobbered, but are
accessed in the parallelized loop.  It is a bit annoying that this
will pessimize virtual operands throughout the whole function, though;
it would be nicer if we were able to specify which variables may be
accessed by a particular call.

> >+   /* Emit OMP_FOR.  */
> >+   TREE_OPERAND (cond, 0) = cvar_base;
> >+   type = TREE_TYPE (cvar);
> >+   t = build_omp_clause (OMP_CLAUSE_SCHEDULE);
> >+   OMP_CLAUSE_SCHEDULE_KIND (t) = OMP_CLAUSE_SCHEDULE_STATIC;
> 
> Do we want to specify this as a --param?  I can see future  
> improvements where we allow the user to determine what scheduling to  
> use and whatnot.  The patch looks like it would support different  
> loop schedulings, or is there something I'm missing?

Yes, that is one of the proposed improvements.  It should basically
just work (by setting different schedule clause here), but it is
completely untested.

I will send an updated patch as soon as possible,

Zdenek



More information about the Gcc-patches mailing list