On Wed, 14 Sep 2022 14:53:54 +0200
Jakub Jelinek <jakub@redhat.com> wrote:

> On Tue, Sep 13, 2022 at 02:03:16PM -0700, Julian Brown wrote:
> > @@ -3440,6 +3437,50 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> > gfc_omp_clauses *clauses, {
> >  		      if (pointer || (openacc && allocatable))
> >  			{
> > +			  gfc_omp_namelist *n2
> > +			    = openacc ? NULL :
> > clauses->lists[OMP_LIST_MAP]; +
> > +			  /* If the last reference is a pointer to
> > a derived
> > +			     type ("foo%dt_ptr"), check if any
> > subcomponents
> > +			     of the same derived type member are
> > being mapped
> > +			     elsewhere in the clause list
> > ("foo%dt_ptr%x",
> > +			     etc.).  If we have such subcomponent
> > mappings,
> > +			     we only create an ALLOC node for the
> > pointer
> > +			     itself, and inhibit mapping the whole
> > derived
> > +			     type.  */
> > +
> > +			  for (; n2 != NULL; n2 = n2->next)
> > +			    {
> > +			      if (n == n2 || !n2->expr)
> > +				continue;
> > +
> > +			      int dep
> > +				= gfc_dep_resolver (n->expr->ref,
> > n2->expr->ref,
> > +						    NULL, true);
> > +			      if (dep == 0)
> > +				continue;  
> 
> Isn't this and the other loop quadratic compile time in number of
> clauses? Could it be done linearly through some perhaps lazily built
> hash table or something similar?

How about this -- a hash table is used to split up the list by the root
symbol the first time we try to resolve dependencies. This arguably
doesn't get rid of the potential for quadratic behaviour *completely*,
but I think the input where it would still be troublesome would be
rather pathological.

I'm not sure how to do better without reimplementing gfc_dep_resolver
or implementing general hashing for Fortran FE expression/symbol nodes,
which isn't there at the moment, so far as I can tell.

I noticed during testing that one of the new added tests for this patch
doesn't actually work until the next patch is in, i.e.:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html

So possibly the patches should be committed squashed together. I
XFAILed the test for now.

Re-tested with offloading to NVPTX. OK?

Thanks,

Julian