Re: [PATCH] PR fortran/31593: Speed up loops with DO variables as procedure arguments

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Richard Henderson wrote:
> > +      if (gfc_is_do_var (expr->symtree->n.sym)
> > +      && !expr->symtree->n.sym->attr.target)
> > +    {
> > +      se->want_pointer = 0;
> > +      gfc_conv_expr (se, expr);
> > +      var = gfc_create_var (TREE_TYPE (se->expr), "arg");
> > +      gfc_add_modify (&se->pre, var, se->expr);
> > +      se->expr = gfc_build_addr_expr (NULL_TREE, var);
> > +      gcc_assert (!se->post.head);
> > +      return;
> > +
>
> This appears to create an arg variable for each instance of the do 
> variable being passed to a call.  That would be wasteful in terms of 
> stack usage.
>
> Better would be to create exactly one arg variable per do variable that 
> needs copying.  And further, for those arg variables to be properly 
> scoped inside the loop, so that arg variables from different loop nests 
> can share stack space (see partition_stack_vars).
>
> Further, since it's illegal for the called function to modify the loop 
> variable, it ought to be illegal for it to modify the stack copy of the 
> loop variable.  Thus it should be possible to write to the copy exactly 
> once, at the beginning of the loop iteration.  Ideally the store would 
> be positioned at the nearest block that dominates all of the uses, but 
> that's obviously hard to do from the front end, and I don't recall that 
> the the optimizers are set up to sink a memory store in that direction.

I thought about doing that, but didn't think it would be worth it: there 
don't appear many calls in loops, and very few actually need this copy. 
 Actually, doing this would be tantamount (save one arithmetic 
operation) to doing away with gfc_trans_simple_do, and that function 
speeds up one benchmark significantly (polyhedron's capacita.f90).

I'll give it a try though, once we figure out where the performance loss 
that Dominique is seeing comes from.

Cheers,
- Tobi