From patchwork Fri Feb 16 15:40:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 85887 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3D3A03857C50 for ; Fri, 16 Feb 2024 15:40:44 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 729ED38582A5 for ; Fri, 16 Feb 2024 15:40:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 729ED38582A5 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 729ED38582A5 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708098018; cv=none; b=ZKb62UmMFLi7AJ+2KFMMCWtrLhwJyLL3ZpsH7quol3hRLw3wLib3LbrzsBl3IasdOCA0mSuKg8EolIhrS1zkERw3CDppC7ghhjZFeBHp3EeIR6ZDj52NeEJnv7wRNvSxlC5ESf7svZq8LD+uCsCtsAvbhUYboYT+DDzXqPQJLoo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708098018; c=relaxed/simple; bh=GX8ip+C3SepAiqCrhIvpef70jf2RavwoG+CCjGKj/6A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=pY/qlKt+yYyt5VTu8wEoPnO54HYYGEIQGo5kTPmcVsjtsabOXwvQM4gRpXFcu1adEnlpe9yaq/yhfbFK+ljFWEF8jBujY0C8PHEDSEqXe/oHdiIRE1BL7V/3SnDbF7hN/xYI+qnsni8YuGEwTh2gVkL8sazQJ6KVoxgdeS/TpOA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-33d00a999b4so968711f8f.0 for ; Fri, 16 Feb 2024 07:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1708098015; x=1708702815; darn=gcc.gnu.org; h=content-language:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=W9jqqF0a4vNHibEm8MYpmsvHXdWFYYUd4UCnyPBt+b8=; b=Cu+ddqa0Os7b4OLO1GoPqF0TUIZZlk0ZwcLPSTaoix46b8wRztOww/11bbiKtP1mTd jjmX5+vlinHzrdtVX9ZYHCdXH7lS2wQCIdCZ56f0hXZW4rGO5Dd+5hoPkyMYI2F8fSTa zUyfljqw3CsKRUM7oyBBvliWK5W6d2lcnFDK0OgUqbFlAK4KGUDrPtgUFfdNSnuM1CRI qwFTgN/DCEnC3Rz85Y6X3M1hub8XxRLOR+i7JaP52MWbqErZnfZXGUeko7prp9MRFhlq HCMiptLYDoosJWegwq0UM98meEROGAyJ3w0ntz/B84B8Dp91BiXH8p3A3yWxMD2nTA0b XzOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708098015; x=1708702815; h=content-language:to:subject:from:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W9jqqF0a4vNHibEm8MYpmsvHXdWFYYUd4UCnyPBt+b8=; b=k4F4iPzdkMMhgYkRkj0HXUQyY2kI+eZCDFvyaYrgDwdFCPzuKcD3IStrsuZDA5e1rT oB5uDxSPmxSHGHeG8B20btt0zWKaW2JZi1NyRwCcb9AEhvpq8O9NEqpLxAGcuiXxCmsB 9m++3kLp90NmHXjaD7O0GdQx2n3jpu01rKbNxfjlT5iaCUzupsrmkLPp4hlJ8u+O1ULR oLxcxmVQutoUCCNTTnlrFsJAWMa7b4//pZeEpH4muYvimS+SejbLhhENe+IjNZrqtPV7 gvu7p98wMtUqHPeZHW3NhcWRxg/8nTL3N5SSL0eCFcHOmI/DH49bKtmTPsG4RHlLGGld bOZg== X-Forwarded-Encrypted: i=1; AJvYcCU+u1GcYkoqeWn+BBTMZIIggVZ7fOn+H96qbbySXlQHwH04ZsZqUhD8/eFKs9mIEs/hm7Chp2W33uj9gQH7p+65Cqw9VDLwCQ== X-Gm-Message-State: AOJu0Yz9rkPwcTYPoNkH8bSmPKS8n8r85wGA43ib9H8cJG8XWYexL2ol YiUqpOkIOHCxQgao7LsJHfRTDuiibxSAsoRZgvQTcsmKEYc1ttm6JKpIWOHlI1w= X-Google-Smtp-Source: AGHT+IH8rzLzIupxbZ9YZE5BIXRv4bdlKwFXAt5kuZ1DizNYvsWsnpYnZEbRNaR0X8m9C3q21TVi3A== X-Received: by 2002:a5d:564f:0:b0:33c:e339:6b21 with SMTP id j15-20020a5d564f000000b0033ce3396b21mr3876842wrw.3.1708098014894; Fri, 16 Feb 2024 07:40:14 -0800 (PST) Received: from ?IPV6:2001:16b8:3fe3:e300:322f:d86c:a5cb:ffc8? ([2001:16b8:3fe3:e300:322f:d86c:a5cb:ffc8]) by smtp.gmail.com with ESMTPSA id g1-20020a056000118100b00337d5cd0d8asm2489404wrx.90.2024.02.16.07.40.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Feb 2024 07:40:14 -0800 (PST) Message-ID: <4d72cb5b-a0d5-4a38-adf1-754a069c4a2c@baylibre.com> Date: Fri, 16 Feb 2024 16:40:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Tobias Burnus Subject: [RFA/RFC] C++/OpenMP: Supporting (first)private for member variables [PR110347] - or VALUE_EXPR and gimplify To: Jakub Jelinek , gcc-patches Content-Language: de-DE, en-US X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org The following works with PARALLEL but not with TARGET. OpenMP states the following is supposed to work: A = 5; // == this->A B = 6; // == this->B C[44] = 7; // == this->C; assume 'int C[100]' #pragma firstprivate(A,C) private(B) { A += 5; // Now: A is 10. B = 7; C[44] += 7; // Now C is 14 // It is unspecified what value this->{A,B,C} has } // {A,B,C[44]} == this->{A,B,C[44]} are still {5,6,7} * * * In the C++ FE, that's handled by creating a temporary variable:      v = create_temporary_var (TREE_TYPE (m)); with      SET_DECL_VALUE_EXPR (v, m); DECL_OMP_PRIVATIZED_MEMBER(v) where 'm' is, e.g., 'this->A' - and a bunch of 'if (DECL_OMP_PRIVATIZED_MEMBER(decl))' in the g++ FE, only. For PARALLEL, the VALUE_EXPR survives until omp-low.cc, which handles this for (first)privatizing. But for TARGET, in gimplify.cc, after the following call in gimplify_omp_workshare 16813 gimple *g = gimplify_and_return_first (OMP_BODY (expr), &body); the 'A' in the body will be turned into 'this->A'. * * * Thus, while there is after omplower the expected #pragma omp target ... firstprivate(A) and also    D.3081 = .omp_data_i->A; A= ...; what actually gets used is    D.3084 = .omp_data_i->D.3046;    this = D.3084;    D.2996 = this->A; which unsurprisingly breaks. * * * This can be "fixed" by using the following patch. With that patch, the -fdump-tree-omplower looks fine. But it does then fail with: during RTL pass: expand g2.cpp:11:7: internal compiler error: in make_decl_rtl, at varasm.cc:1443 for the 'A' with 'B = A' (where B is a non-member var) and 'A' is still as the value expr 'this->A'. } * * * Any idea / suggestion how to handle this best? One way I see would be to add a lang-hook here to check for DECL_OMP_PRIVATIZED_MEMBER, similar to the hack above. And then ensure that the DECL_VALUE_EXPR points to the var decl in the target region (i.e. some hacking in omp-low.cc). I have no idea whether that would - nor whether that would be the way forward. - Thoughts? Tobias --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -3285,12 +3285,15 @@ gimplify_var_or_parm_decl (tree *expr_p) if (gimplify_omp_ctxp && omp_notice_variable (gimplify_omp_ctxp, decl, true)) return GS_ALL_DONE; + if (!flag_openmp) // Assume: C++'s DECL_OMP_PRIVATIZED_MEMBER (decl) + { /* If the decl is an alias for another expression, substitute it. */ if (DECL_HAS_VALUE_EXPR_P (decl)) { *expr_p = unshare_expr (DECL_VALUE_EXPR (decl)); return GS_OK; } + } return GS_ALL_DONE;