From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 8E1B938582AE for ; Mon, 6 Jun 2022 17:32:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E1B938582AE Received: by mail-wr1-x435.google.com with SMTP id t13so20786582wrg.9 for ; Mon, 06 Jun 2022 10:32:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=29M82tHHr//XuMtOYoPzahr2c218kZdaOm9bpyJI+BI=; b=TwwhBhckz5d7mJc/bWmJxTdYSxwGLB3DfWFO+agzjSd9Nln4EmFh/WA8OIMt5RpEAb D9jBmf+KI+d7cdCbS6WnsbMCTKRYjwshEx4GYrFbqngAwPz6vfQwVADrRunty0HPrnsu j0tnrmeUTs4DTPf6aQI5lsGL1jNoTWOwciaRyoj5ZVLVOWYYTow7w+EYf2rFbbL+2oKI VREJUV0mSR3Ti3xhqEhx0tBxCejK4/QDsrnrHfHoDZw/f9nrw3GaDTSNoZirpryLZOg/ ZsBz8WRdp+SHKiE/hj2FyTrHUD3PkA8ra88JyllnoKSjQi7mJoFXc2NrELI1ghV9cM2U xsMg== X-Gm-Message-State: AOAM531OrR8M+RYx/zsKdhPN7kQAdD2VsXdOr20/CmkzQRdT9Km1M7u4 Us+xDe0NTxXqZG6zIp0riCWbRKzO3YpoCziWFRQ= X-Google-Smtp-Source: ABdhPJyriY+o8wCDmaNsRhE5NGNaGzDrznADctR+27IV6QPUzpOui3eS8jvrT2jQB5vJRzmiec6bbmKyhyKyyo2q9bA= X-Received: by 2002:adf:fb90:0:b0:20c:62bd:652d with SMTP id a16-20020adffb90000000b0020c62bd652dmr23127699wrr.402.1654536764827; Mon, 06 Jun 2022 10:32:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mohamed Atef Date: Mon, 6 Jun 2022 19:32:31 +0200 Message-ID: Subject: Re: [PATCH]: libgompd add parallel handle functions To: Jakub Jelinek Cc: Mohamed Sayed , gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:32:48 -0000 =D9=81=D9=8A =D8=A7=D9=84=D8=A7=D8=AB=D9=86=D9=8A=D9=86=D8=8C =D9=A6 =D9=8A= =D9=88=D9=86=D9=8A=D9=88=D8=8C =D9=A2=D9=A0=D9=A2=D9=A2 =D9=A7:=D9=A1=D9=A3= =D9=85 Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> =D9=83=D8=AA=D8=A8: > 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 t= he > > 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)= . > I think the implementation is correct But there's a typo in the comment. > > > 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.tea= m, > 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 represen= t > somehow too. > So for both cases one should read the value of *team and if it's NULL, the function returns some error state (eg. ompd_rc_unavailable) > > 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 anythin= g. > One possibility to resolve this is perhaps if all functions that > allocate ompd_task_handle_t can't know the corresponding struct gomp_thre= ad > too, then you could store in the private structure or ompd_task_handle_t > both struct gomp_task * and struct gomp_thread *. > I will ask the guys to try this if it's impossible then we delay this function. > If that is impossible, we could add such a pointer, but it would increase > both memory and runtime overhead of the library. > > Jakub > >