From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CDFA23857BAB for ; Mon, 30 May 2022 11:13:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDFA23857BAB Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-152-Zk_xWPCdPEeXVrBD-7gQ8w-1; Mon, 30 May 2022 07:13:45 -0400 X-MC-Unique: Zk_xWPCdPEeXVrBD-7gQ8w-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B414C38149A4; Mon, 30 May 2022 11:13:44 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.33.36.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78AAB2166B2A; Mon, 30 May 2022 11:13:44 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 24UBDfwY3614075 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 30 May 2022 13:13:42 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 24UBDfei3614074; Mon, 30 May 2022 13:13:41 +0200 Date: Mon, 30 May 2022 13:13:40 +0200 From: Jakub Jelinek To: Kwok Cheung Yeung Cc: gcc-patches Subject: Re: [PATCH 3/7] openmp: Add support for resolving metadirectives during parsing and Gimplification Message-ID: Reply-To: Jakub Jelinek References: <3570a7bc-fbf1-93f1-9a20-a788e4e707f2@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <3570a7bc-fbf1-93f1-9a20-a788e4e707f2@codesourcery.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2022 11:13:48 -0000 On Fri, Dec 10, 2021 at 05:35:05PM +0000, Kwok Cheung Yeung wrote: > 2021-12-10 Kwok Cheung Yeung > > 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 &candidates, > + hash_map &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 &) > +c_omp_expand_metadirective (vec &candidates) > { > - return NULL_TREE; > + hash_map 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