From: Thomas Schwinge <thomas@codesourcery.com>
To: Julian Brown <julian@codesourcery.com>, <gcc-patches@gcc.gnu.org>
Cc: Andrew Stubbs <ams@codesourcery.com>, <fortran@gcc.gnu.org>
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)
Date: Thu, 20 Oct 2022 12:05:28 +0200 [thread overview]
Message-ID: <87lepahkt3.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <20221014133856.3388109-1-julian@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]
Hi!
On 2022-10-14T13:38:55+0000, Julian Brown <julian@codesourcery.com> 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_APERTURE_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 [PR105421]",
see attached.
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-amdgcn-Use-FLAT-addressing-for-all-functions-with-po.patch --]
[-- Type: text/x-diff, Size: 3108 bytes --]
From 7c55755d4c760de326809636531478fd7419e1e5 Mon Sep 17 00:00:00 2001
From: Julian Brown <julian@codesourcery.com>
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 <julian@codesourcery.com>
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
next prev parent reply other threads:[~2022-10-20 10:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 13:38 [PATCH] [og12] amdgcn: Use FLAT addressing for all functions with pointer arguments Julian Brown
2022-10-14 13:38 ` [PATCH] [og12] OpenACC: Don't gang-privatize artificial variables Julian Brown
2022-10-18 14:46 ` Thomas Schwinge
2022-10-18 14:59 ` Julian Brown
2022-10-28 8:11 ` [og12] OpenACC: Don't gang-privatize artificial variables: restrict to blocks (was: [PATCH] [og12] OpenACC: Don't gang-privatize artificial variables) Thomas Schwinge
2022-10-28 8:20 ` Thomas Schwinge
2022-10-28 8:51 ` OpenACC: Don't gang-privatize artificial variables [PR90115] " Thomas Schwinge
2022-10-20 10:05 ` Thomas Schwinge [this message]
2022-10-20 10:19 ` Add 'libgomp.oacc-c-c++-common/private-big-1.c' [PR105421] (was: amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421]) Thomas Schwinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lepahkt3.fsf@euler.schwinge.homeip.net \
--to=thomas@codesourcery.com \
--cc=ams@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=julian@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).