From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 2D3B6385618C; Thu, 20 Oct 2022 10:05:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D3B6385618C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,198,1661846400"; d="scan'208,223";a="87909089" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 20 Oct 2022 02:05:44 -0800 IronPort-SDR: cTdwRhAG4VVGt1VSbwp5PknAatr0Z2ALOZ/2+PzCdn+m0JK2FFcECeBEHb4Nb/W5YhUx8TbN22 P7zNIBoJBqYFqCGxVXso3kwya0/NQea2yxRoSVoLy4uokpb2cAZHn2KCqQZYSECzDo/MjVysMV yUByn15v3Co1oFcnxEhMpEH6loQdyeHubGteLwA/mA9FCEOA1xiAcJ5Dt2DUu5VonI0bARW1rc OrandLLU7nGkAJ28e/jOJR+ZtrYnqboC5C3kHzI5PtkFrbh8Kvsrsiw5ad9roR2CLIUlpY3xeZ EB8= From: Thomas Schwinge To: Julian Brown , CC: Andrew Stubbs , Subject: amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421] (was: [PATCH] [og12] amdgcn: Use FLAT addressing for all functions with pointer arguments) In-Reply-To: <20221014133856.3388109-1-julian@codesourcery.com> References: <20221014133856.3388109-1-julian@codesourcery.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Thu, 20 Oct 2022 12:05:28 +0200 Message-ID: <87lepahkt3.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi! On 2022-10-14T13:38:55+0000, Julian Brown wrote: > The GCN backend uses a heuristic to determine whether to use FLAT or > GLOBAL addressing in a particular (offload) function: namely, if a > function takes a pointer-to-scalar parameter, it is assumed that the > pointer may refer to "flat scratch" space, and thus FLAT addressing must > be used instead of GLOBAL. > > I came up with this heuristic initially whilst working on support for > moving OpenACC gang-private variables into local-data share (scratch) > memory. The assumption that only scalar variables would be transformed in > that way turned out to be wrong. For example, prior to the next patch in > the series, Fortran compiler-generated temporary structures were treated > as gang private and moved to LDS space, typically overflowing the region > allocated for such variables. That will no longer happen after that > patch is applied, but there may be other cases of structs moving to LDS > space now or in the future that this patch may be needed for. > > Tested with offloading to AMD GCN. I will apply shortly (to og12). Thanks. I've verified that this does resolve PR105421 "GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APE= RTURE_VIOLATION'" and have thus added PR105421 tags to your commit log, and with that pushed to master branch commit 7c55755d4c760de326809636531478fd7419e1e5 "amdgcn: Use FLAT addressing for all functions with pointer arguments [PR10= 5421]", see attached. Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename="0001-amdgcn-Use-FLAT-addressing-for-all-functions-with-po.patch" >From 7c55755d4c760de326809636531478fd7419e1e5 Mon Sep 17 00:00:00 2001 From: Julian Brown Date: Fri, 14 Oct 2022 11:06:07 +0000 Subject: [PATCH] amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421] The GCN backend uses a heuristic to determine whether to use FLAT or GLOBAL addressing in a particular (offload) function: namely, if a function takes a pointer-to-scalar parameter, it is assumed that the pointer may refer to "flat scratch" space, and thus FLAT addressing must be used instead of GLOBAL. I came up with this heuristic initially whilst working on support for moving OpenACC gang-private variables into local-data share (scratch) memory. The assumption that only scalar variables would be transformed in that way turned out to be wrong. For example, prior to the next patch in the series, Fortran compiler-generated temporary structures were treated as gang private and moved to LDS space, typically overflowing the region allocated for such variables. That will no longer happen after that patch is applied, but there may be other cases of structs moving to LDS space now or in the future that this patch may be needed for. 2022-10-14 Julian Brown PR target/105421 gcc/ * config/gcn/gcn.cc (gcn_detect_incoming_pointer_arg): Any pointer argument forces FLAT addressing mode, not just pointer-to-non-aggregate. --- gcc/config/gcn/gcn.cc | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc index 8777255a5c6..a9ef5c3dc02 100644 --- a/gcc/config/gcn/gcn.cc +++ b/gcc/config/gcn/gcn.cc @@ -2809,10 +2809,14 @@ gcn_arg_partial_bytes (cumulative_args_t cum_v, const function_arg_info &arg) return (NUM_PARM_REGS - cum_num) * regsize; } -/* A normal function which takes a pointer argument (to a scalar) may be - passed a pointer to LDS space (via a high-bits-set aperture), and that only - works with FLAT addressing, not GLOBAL. Force FLAT addressing if the - function has an incoming pointer-to-scalar parameter. */ +/* A normal function which takes a pointer argument may be passed a pointer to + LDS space (via a high-bits-set aperture), and that only works with FLAT + addressing, not GLOBAL. Force FLAT addressing if the function has an + incoming pointer parameter. NOTE: This is a heuristic that works in the + offloading case, but in general, a function might read global pointer + variables, etc. that may refer to LDS space or other special memory areas + not supported by GLOBAL instructions, and then this argument check would not + suffice. */ static void gcn_detect_incoming_pointer_arg (tree fndecl) @@ -2822,8 +2826,7 @@ gcn_detect_incoming_pointer_arg (tree fndecl) for (tree arg = TYPE_ARG_TYPES (TREE_TYPE (fndecl)); arg; arg = TREE_CHAIN (arg)) - if (POINTER_TYPE_P (TREE_VALUE (arg)) - && !AGGREGATE_TYPE_P (TREE_TYPE (TREE_VALUE (arg)))) + if (POINTER_TYPE_P (TREE_VALUE (arg))) cfun->machine->use_flat_addressing = true; } -- 2.35.1 --=-=-=--