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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 99B563985416 for ; Thu, 29 Oct 2020 10:03:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99B563985416 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-508-IadA4aHMOxOOw_vLEJTcGg-1; Thu, 29 Oct 2020 06:03:17 -0400 X-MC-Unique: IadA4aHMOxOOw_vLEJTcGg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4AE7D64168; Thu, 29 Oct 2020 10:03:16 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-188.ams2.redhat.com [10.36.113.188]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A11175B4CA; Thu, 29 Oct 2020 10:03:15 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 09TA3C1T871908 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 29 Oct 2020 11:03:12 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 09TA3BPZ871907; Thu, 29 Oct 2020 11:03:11 +0100 Date: Thu, 29 Oct 2020 11:03:11 +0100 From: Jakub Jelinek To: Kwok Cheung Yeung Cc: GCC Patches Subject: Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers Message-ID: <20201029100311.GC3788@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 29 Oct 2020 10:03:21 -0000 On Wed, Oct 28, 2020 at 02:20:29PM +0000, Kwok Cheung Yeung wrote: > OpenMP 5.0 has a new feature for implicitly marking variables and functions > that are referenced in the initializers of static variables and functions > that are already marked 'declare target'. Support was added in the commit > 'openmp: Implement discovery of implicit declare target to clauses' > (dc703151d4f4560e647649506d5b4ceb0ee11e90). However, this does not work with > non-constant C++ initializers, where the initializers can contain references > to other (non-constant) variables and function calls. > > The C++ front-end stores the initialization information in the > static_aggregates list (with the variable decl in the TREE_VALUE of an entry > and the initialization in TREE_PURPOSE) rather than in > TREE_INITIAL(var_decl). I have added an extra function in omp-offload.cpp to > walk the variable initialiser trees in static_aggregates, and added a call > to it from the FE shortly before the initializations are emitted. I have > also added a testcase to ensure that the implicitly marked > variables/functions can be referenced in offloaded code. I'm actually not sure how this can work correctly. Let's say we have int foo () { return 1; } int bar () { return 2; } int baz () { return 3; } int qux () { return 4; } int a = foo (); int b = bar (); int c = baz (); int *d = &c; int e = qux (); int f = e + 1; int *g = &f; #pragma omp declare target to (b, d, g) So, for the implicit declare target discovery, a is not declare target to, nor is foo, and everything else is; b, d, g explicitly, c because it is referenced in initializer of b, f because it is mentioned in initializer of g and e because it is mentioned in initializer of f. Haven't checked if the new function you've added is called before or after analyze_function calls omp_discover_implicit_declare_target, but I don't really see how it can work when it is not inside of that function, so that discovery of new static vars that are implicitly declare target to doesn't result in marking of its dynamic initializers too. Perhaps we need a langhook for that. But if it is a separate function, either it is called before the other discovery and will ignore static initializers for vars that will only be marked as implicit declare target to later, or it is done afterwards, but then it would really need to duplicate everything what the other function does, otherwise it woiuldn't discover everything. Anyway, that is one thing, the other is even if the implicit declare target discovery handles those correctly, the question is what should we do afterwards. Because the C++ FE normally creates a single function that performs the dynamic initialization of the TUs variables. But that function shouldn't be really declare target to, it initializes not only (explicit or implicit) declare target to variables, but also host only variables. So we'll probably need to create next to that host only TU constructor also a device only constructor function that will only initialize the declare target to variables. Jakub