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 410E63857B86 for ; Mon, 6 Jun 2022 17:12:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 410E63857B86 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-464-urzaHEziPU-JpFeHNMHDYQ-1; Mon, 06 Jun 2022 13:12:41 -0400 X-MC-Unique: urzaHEziPU-JpFeHNMHDYQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 626AC3C60520; Mon, 6 Jun 2022 17:12:41 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1E1B71121314; Mon, 6 Jun 2022 17:12:41 +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 256HCcg0192580 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 6 Jun 2022 19:12:38 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 256HCbdp192579; Mon, 6 Jun 2022 19:12:37 +0200 Date: Mon, 6 Jun 2022 19:12:37 +0200 From: Jakub Jelinek To: Mohamed Sayed Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH]: libgompd add parallel handle functions Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 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.8 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, 06 Jun 2022 17:12:44 -0000 On Mon, Jun 06, 2022 at 01:48:22AM +0200, Mohamed Sayed via Gcc-patches wrote: > This patch adds parallel region handles specified in section 5.5.3. > >From examining libgomp code, I found that struct gomp_team describes the > parallel region. I think it would be nice to first find out what the different ompd_{parallel,thread,task}_handle_t should actually contain. In GOMP, the first one maps to struct gomp_team, the middle one to struct gomp_thread and the last one to struct gomp_task. Functions that create those are: For ompd_thread_handle_t that is ompd_get_thread_in_parallel and ompd_get_thread_handle. For ompd_parallel_handle_t that is ompd_get_curr_parallel_handle, ompd_get_enclosing_parallel_handle and ompd_get_task_parallel_handle. For ompd_task_handle_t that is ompd_get_curr_task_handle, ompd_get_generating_task_handle, ompd_get_scheduling_task_handle and ompd_get_task_in_parallel. What those handles point to is something libgompd allocates using the allocator callback and it is up to the library what it puts there, typically it should contain the address of those corresponding gomp structures and whatever else is needed (say address space handle or some contexts). > The Thread handle gives the address of gomp_thread so, I tried to > access *team > gomp_thread->ts->team. Actually gomp_thread's ts.team (ts is not a pointer, but a nested struct). > The parallel handle is the team pointer in team state. > I have a question about ompd_get_task_parallel_handle > https://www.openmp.org/spec-html/5.0/openmpsu218.html > How can i reach gomp_team from gomp_taske > And the union in gomp_task has two entries gomp_sem_t and gomp_team So, for the 4 functions you want to implement: ompd_get_curr_parallel_handle when you'll have struct gomp_thread * and want struct gomp_team * you load thr->ts.team. Note, the implicit parallel is usually represented by NULL in thr->ts.team, that case then means it has just a single thread etc. ompd_get_enclosing_parallel_handle when you'll have struct gomp_team * and want the enclosing team. team->prev_ts.team is what you are after, if it is non-NULL, it is the enclosing parallel, if it is NULL, I think one should verify e.g. host teams construct in that case, but otherwise it is the implicit parallel that one probably needs to represent somehow too. ompd_get_task_parallel_handle when you'll have struct gomp_task * and want the struct gomp_team it is in. I'm afraid the library doesn't track this, it doesn't need it for anything. One possibility to resolve this is perhaps if all functions that allocate ompd_task_handle_t can't know the corresponding struct gomp_thread too, then you could store in the private structure or ompd_task_handle_t both struct gomp_task * and struct gomp_thread *. If that is impossible, we could add such a pointer, but it would increase both memory and runtime overhead of the library. Jakub