Re: [PATCH 3/7] openmp: Add support for resolving metadirectives during parsing and Gimplification

[Jakub Jelinek <jakub@redhat.com>]

On Fri, Dec 10, 2021 at 05:35:05PM +0000, Kwok Cheung Yeung wrote:
> 2021-12-10  Kwok Cheung Yeung  <kcy@codesourcery.com>
> 
> 	gcc/
> 	* gimplify.c (expand_omp_metadirective): New.
> 	* omp-general.c: Include tree-pretty-print.h.
> 	(DELAY_METADIRECTIVES_AFTER_LTO): New macro.
> 	(omp_context_selector_matches): Delay resolution of selectors.  Allow
> 	non-constant expressions.
> 	(omp_dynamic_cond): New.
> 	(omp_dynamic_selector_p): New.
> 	(sort_variant): New.
> 	(omp_get_dynamic_candidates): New.
> 	(omp_resolve_metadirective): New.
> 	(omp_resolve_metadirective): New.
> 	* omp-general.h (struct omp_metadirective_variant): New.
> 	(omp_resolve_metadirective): New prototype.
> 
> 	gcc/c-family/
> 	* c-omp.c (c_omp_expand_metadirective_r): New.
> 	(c_omp_expand_metadirective): New.

> --- a/gcc/c-family/c-omp.c
> +++ b/gcc/c-family/c-omp.c
> @@ -3264,8 +3264,49 @@ c_omp_categorize_directive (const char *first, const char *second,
>    return NULL;
>  }
>  

Missing function comment.

> +static tree
> +c_omp_expand_metadirective_r (vec<struct omp_metadirective_variant> &candidates,
> +			      hash_map<tree, tree> &body_labels,
> +			      unsigned index)
> +{
> +  struct omp_metadirective_variant &candidate = candidates[index];
> +  tree if_block = push_stmt_list ();
> +  if (candidate.directive != NULL_TREE)
> +    add_stmt (candidate.directive);
> +  if (candidate.body != NULL_TREE)
> +    {
> +      tree *label = body_labels.get (candidate.body);
> +      if (label != NULL)
> +	add_stmt (build1 (GOTO_EXPR, void_type_node, *label));
> +      else
> +	{
> +	  tree body_label = create_artificial_label (UNKNOWN_LOCATION);
> +	  add_stmt (build1 (LABEL_EXPR, void_type_node, body_label));
> +	  add_stmt (candidate.body);
> +	  body_labels.put (candidate.body, body_label);
> +	}
> +    }
> +  if_block = pop_stmt_list (if_block);
> +
> +  if (index == candidates.length () - 1)
> +    return if_block;
> +
> +  tree cond = candidate.selector;
> +  gcc_assert (cond != NULL_TREE);
> +
> +  tree else_block = c_omp_expand_metadirective_r (candidates, body_labels,
> +						  index + 1);
> +  tree ret = push_stmt_list ();
> +  tree stmt = build3 (COND_EXPR, void_type_node, cond, if_block, else_block);
> +  add_stmt (stmt);
> +  ret = pop_stmt_list (ret);
> +
> +  return ret;
> +}
> +

Likewise.

>  tree
> -c_omp_expand_metadirective (vec<struct omp_metadirective_variant> &)
> +c_omp_expand_metadirective (vec<struct omp_metadirective_variant> &candidates)
>  {
> -  return NULL_TREE;
> +  hash_map<tree, tree> body_labels;
> +  return c_omp_expand_metadirective_r (candidates, body_labels, 0);
>  }

> --- a/gcc/omp-general.c
> +++ b/gcc/omp-general.c
> @@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "data-streamer.h"
>  #include "streamer-hooks.h"
>  #include "opts.h"
> +#include "tree-pretty-print.h"
>  
>  enum omp_requires omp_requires_mask;
>  
> @@ -1253,14 +1254,22 @@ omp_context_name_list_prop (tree prop)
>      }
>  }
>  
> +#define DELAY_METADIRECTIVES_AFTER_LTO { \
> +  if (metadirective_p && !(cfun->curr_properties & PROP_gimple_lomp_dev))	\
> +    return -1;	\

Why this?  Is that just some testing hack (which then the choice of
selectors in the testsuite relies on)?  I don't see why those selectors
shouldn't be resolved as early as possible.

> @@ -2624,16 +2673,189 @@ omp_lto_input_declare_variant_alt (lto_input_block *ib, cgraph_node *node,
>  						 INSERT) = entryp;
>  }
>  

Missing function comment.

> +static int
> +sort_variant (const void * a, const void *b, void *)
> +{
> +  widest_int score1 = ((const struct omp_metadirective_variant *) a)->score;
> +  widest_int score2 = ((const struct omp_metadirective_variant *) b)->score;
> +
> +  if (score1 > score2)
> +    return -1;
> +  else if (score1 < score2)
> +    return 1;
> +  else
> +    return 0;
> +}

Note, resolving at the end of parsing (during gimplification) is still not
during parsing.  For resolving during parsing we'll need another mode, in
which the FEs somehow track e.g. selected OpenMP constructs that surround
the code being currently parsed.  Obviously that can be handled
incrementally.

	Jakub