On Fri, Aug 09, 2024 at 07:12:48PM +0200, Jakub Jelinek wrote:
> > --- a/gcc/gimple.def
> > +++ b/gcc/gimple.def
> > @@ -398,6 +398,13 @@ DEFGSCODE(GIMPLE_OMP_TEAMS, "gimple_omp_teams",
> > GSS_OMP_PARALLEL_LAYOUT)
> > CLAUSES is an OMP_CLAUSE chain holding the associated clauses. */
> > DEFGSCODE(GIMPLE_OMP_ORDERED, "gimple_omp_ordered", GSS_OMP_SINGLE_LAYOUT)
> >
> > +/* GIMPLE_OMP_METADIRECTIVE represents #pragma omp metadirective. */
> > +DEFGSCODE(GIMPLE_OMP_METADIRECTIVE, "gimple_omp_metadirective",
> > + GSS_OMP_METADIRECTIVE)
> > +
> > +DEFGSCODE(GIMPLE_OMP_METADIRECTIVE_VARIANT,
> > + "gimple_omp_variant", GSS_OMP_METADIRECTIVE_VARIANT)
> > +
Oh, and I wonder if there shouldn't be a different representation of this in
GIMPLE.
GIMPLE_OMP_METADIRECTIVE in the patch seems to have both the TREE_LISTs for
the variants and the labels.
We already have a construct which can have a set of labels, GIMPLE_SWITCH,
and tons of optimizations available for it.
Can't GIMPLE_OMP_METADIRECTIVE be just the list of TREE_LISTs for the
variants which sets some integer SSA_NAME with a GIMPLE_SWITCH next to it
which picks what code will be used? And, to simplify the SSA scanners,
perhaps have the device_num and condition operands hoisted to separate ops.
So, ops[0] would be the output, artificial integer result used in
GIMPLE_SWITCH, ops[1] say condition SSA_NAME (if dynamic condition isn't
used, then boolean_true_node), ops[2] say device_num SSA_NAME (if unused
some negative INTEGER_CST which can't otherwise happen)?
Perhaps we'd want to avoid GIMPLE_SWITCH lowering if the controlling
SSA_NAME has GIMPLE_OMP_METADIRECTIVE def_stmt (because we expect it to
fold into a constant), but otherwise other GIMPLE_SWITCH optimizations might
be ok.
What do you think? Or am I missing something?
Jakub
