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 09E02386CE40 for ; Thu, 30 Jun 2022 08:21:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09E02386CE40 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-MYAYXF0LNqSGSBl-Nyah3w-1; Thu, 30 Jun 2022 04:21:23 -0400 X-MC-Unique: MYAYXF0LNqSGSBl-Nyah3w-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08E858041BC; Thu, 30 Jun 2022 08:21:23 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD2D1492C3B; Thu, 30 Jun 2022 08:21:22 +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 25U8LKcb4005416 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 30 Jun 2022 10:21:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 25U8LIY64005415; Thu, 30 Jun 2022 10:21:18 +0200 Date: Thu, 30 Jun 2022 10:21:18 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches Subject: Re: [Patch] OpenMP: Prepare omp-* for ancestor:1 handling Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 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.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, 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: 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, 30 Jun 2022 08:21:28 -0000 On Wed, Jun 29, 2022 at 09:54:56PM +0200, Tobias Burnus wrote: > Currently, this is a rather useless patch - even though it helps to reduce > the number of local patches I have. Due to the printed sorry, adding a > testcase with -fdump-tree-* is also not possible, yet. > > For reverse offload, the plan is to call > GOMP_target_ext > inside the on the device, passing > 'device(omp_initial_device)' > alias device(GOMP_DEVICE_HOST_FALLBACK) to the > target device's libgomp. > > The pointer to the generated target-region function is then > passed as argument. However, that only works if that function > is not nullified ... > > The reason that nullifying was added is: > https://gcc.gnu.org/PR100573 > https://gcc.gnu.org/r12-1066-g95d67762171f83277a5700b270c0d1e2756f83f4 > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571285.html > > > Note: Instead of just checking for GOMP_DEVICE_HOST_FALLBACK, > more effort could be done, e.g. by setting some attribute on the > generated function and then check for check for it. Example: > 'omp target device_ancestor' + using lookup_attribute). > > That's what's done in the second variant. > > OK for mainline (which variant)? Or do you prefer to wait for > a more complete patch? So, what is the plan with reverse offload? Which devices can do it? I presume we won't bother with intelmic, can gcn do it and how, can nvptx do it and how? What we could do is implement it initially (with all the restriction checking etc. needed) for host fallback only, say no devices support reverse offload and take out the sorry. But it would be good to at least have some idea how it will be implemented for some offloading devices, whether map will there anything at all (or it will require unified shared memory) and how we'll map the fn argument passed to GOMP_target_ext back to the host function address. Jakub