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.129.124]) by sourceware.org (Postfix) with ESMTPS id 52A7A3857BBB for ; Wed, 25 May 2022 13:37:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52A7A3857BBB 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-91-BpgPG46VPViHylkIngEE4A-1; Wed, 25 May 2022 09:37:15 -0400 X-MC-Unique: BpgPG46VPViHylkIngEE4A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6A1253C021B6; Wed, 25 May 2022 13:37:15 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.106]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 23F39400F3E7; Wed, 25 May 2022 13:37:14 +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 24PDbCuG039801 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 25 May 2022 15:37:12 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 24PDbBv8039799; Wed, 25 May 2022 15:37:11 +0200 Date: Wed, 25 May 2022 15:37:11 +0200 From: Jakub Jelinek To: Julian Brown , gcc-patches@gcc.gnu.org, Thomas Schwinge , Tobias Burnus , Fortran List Subject: Re: [PATCH v2 09/11] OpenMP 5.0 "declare mapper" support for C++ Message-ID: Reply-To: Jakub Jelinek References: <446929ccca41031c43ca38c6f5ce2141422a2a0d.1647619145.git.julian@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 13:37:21 -0000 On Tue, May 24, 2022 at 04:48:13PM +0200, Jakub Jelinek wrote: > > This version of the patch improves detection of explicitly-mapped struct > > accesses which inhibit implicitly-triggered user-defined mappers for a > > target region. > > Will start with a general comment, from looking at the dumps it seems > handling the mappers in the FE right away for explicit mapping clauses > and attaching mapper binding clauses for types that are (or could > conservatively be, including from the recursive mappers themselves) be > used in the target body and letting gimplification find those var in detail > and use mapper binding clauses to actually expand it looks like the right > approach to me. As I raised in an earlier patch, a big question is if we > should do map clause sorting on gimplify_scan_omp_clauses or > gimplify_adjust_omp_clauses or both... > The conservative discovery of what types we might need to create mapper > binding clauses for should be probably done only if > !processing_template_decl. Oh, and one very important thing I forgot to say yesterday. With declare mapper but even the general mapping of aggregate is mapping of all its members/elements individually, we are going to end up with huge mapping lists. We need to undo that at compile time whenever possible, so if we after the declare mapper handling (from explicit or implicit mappings) and sorting the mapping clauses see that we have say struct S { int x, y, z[2], w; } s; and we see map (tofrom: s.x, s.y, s.z[0], s.z[1], s.w) we should turn that back into map (tofrom: s). Basically optimize consecutive mappings of the same kind to one that covers them together. Then there is the question of padding bits, if there is reasonably small padding in between mapped fields we could be mapping the padding too. Jakub