On 8/10/24 02:02, Jakub Jelinek wrote:
On Sat, Aug 10, 2024 at 09:18:24AM +0200, Jakub Jelinek wrote:
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?
Please ignore the part about dynamic condition/device_num, each variant
obviously will have its own. But the rest stands.
I think I understand the general idea you're getting at. Just FYI, as
part of addressing this, I'm going to do some patch refactoring to
incorporate some further changes to GIMPLE_OMP_METADIRECTIVE that I had
in part 9 of the series, where I extended it to also handle the
call-site dispatch for "#pragma omp declare variant" with dynamic
selectors. I was never very happy about using the original name
GIMPLE_OMP_METADIRECTIVE for both things, and looking at it now I think
GIMPLE_OMP_VARIANT_DIRECTIVE is probably a better choice. WDYT?
-Sandra
