public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Julian Brown <julian@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>, Andrew Stubbs <ams@codesourcery.com>,
	<fortran@gcc.gnu.org>
Subject: Re: [PATCH] [og12] OpenACC: Don't gang-privatize artificial variables
Date: Tue, 18 Oct 2022 16:46:07 +0200	[thread overview]
Message-ID: <878rldur4g.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <20221014133856.3388109-2-julian@codesourcery.com>

Hi Julian!

On 2022-10-14T13:38:56+0000, Julian Brown <julian@codesourcery.com> wrote:
> This patch prevents compiler-generated artificial variables from being
> treated as privatization candidates for OpenACC.
>
> The rationale is that e.g. "gang-private" variables actually must be
> shared by each worker and vector spawned within a particular gang, but
> that sharing is not necessary for any compiler-generated variable (at
> least at present, but no such need is anticipated either).  Variables on
> the stack (and machine registers) are already private per-"thread"
> (gang, worker and/or vector), and that's fine for artificial variables.

OK, that seems fine rationale for this change in behavior.
No contradicting test case jumped onto me, either.

> Several tests need their scan output patterns adjusted to compensate.

ACK -- surprisingly few.  (Some minor fine-tuning necessary for GCC
master branch, as had to be expected; I'm working on that.)

> --- a/gcc/omp-low.cc
> +++ b/gcc/omp-low.cc
> @@ -11400,6 +11400,28 @@ oacc_privatization_candidate_p (const location_t loc, const tree c,
>       }
>      }
>
> +  /* If an artificial variable has been added to a bind, e.g.
> +     a compiler-generated temporary structure used by the Fortran front-end, do
> +     not consider it as a privatization candidate.  Note that variables on
> +     the stack are private per-thread by default: making them "gang-private"
> +     for OpenACC actually means to share a single instance of a variable
> +     amongst all workers and threads spawned within each gang.
> +     At present, no compiler-generated artificial variables require such
> +     sharing semantics, so this is safe.  */
> +
> +  if (res && DECL_ARTIFICIAL (decl))
> +    {
> +      res = false;
> +
> +      if (dump_enabled_p ())
> +     {
> +       oacc_privatization_begin_diagnose_var (l_dump_flags, loc, c, decl);
> +       dump_printf (l_dump_flags,
> +                    "isn%'t candidate for adjusting OpenACC privatization "
> +                    "level: %s\n", "artificial");
> +     }
> +    }

In the source code comment, you say "added to a bind", and that's indeed
what I was expecting, too, and thus put in:

       if (res && DECL_ARTIFICIAL (decl))
         {
    +      gcc_checking_assert (block);
    +
           res = false;

..., but to my surprised, that did fire in one occasion:

> --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
> @@ -94,9 +94,7 @@ contains
>      !$acc parallel copy(array)
>      !$acc loop gang private(array) ! { dg-line l_loop[incr c_loop] }
>      ! { dg-note {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'array\.[0-9]+' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'array\.[0-9]+' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'array\.[0-9]+' adjusted for OpenACC privatization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc_nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop }
> +    ! { dg-note {variable 'array\.[0-9]+' in 'private' clause isn't candidate for adjusting OpenACC privatization level: artificial} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-message {sorry, unimplemented: target cannot support alloca} PR65181 { target openacc_nvidia_accel_selected } l_loop$c_loop }
>      do i = 1, 10
>        array(i) = 9*i

... here.  Note "variable 'array\.[0-9]+' in 'private' clause";
everywhere else we have "declared in block".

As part of your verification, have you already looked into whether the
new behavior is correct here, or does this one need to continue to be
"adjusted for OpenACC privatization level: 'gang'"?  If the latter,
should we check 'if (res && block && DECL_ARTIFICIAL (decl))' instead of
'if (res && DECL_ARTIFICIAL (decl))', or is there some wrong setting of
'DECL_ARTIFICIAL' -- or are we maybe looking at an inappropriate 'decl'?
(Thinking of commit r12-7580-g7a5e036b61aa088e6b8564bc9383d37dfbb4801e
"[OpenACC privatization] Analyze 'lookup_decl'-translated DECL [PR90115, PR102330, PR104774]",
for example.)


Grüße
 Thomas


> @@ -122,9 +120,7 @@ contains
>      ! { dg-note {variable 'str' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-note {variable 'str' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-note {variable 'str' adjusted for OpenACC privatization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc_nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' adjusted for OpenACC privatization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc_nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop }
> +    ! { dg-note {variable 'char\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: artificial} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-message {sorry, unimplemented: target cannot support alloca} PR65181 { target openacc_nvidia_accel_selected } l_loop$c_loop }
>      do i = 1, 10
>        str(i:i) = achar(ichar('A') + i)
> @@ -167,9 +163,7 @@ contains
>      ! { dg-note {variable 'scalar' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-note {variable 'scalar' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
>      ! { dg-note {variable 'scalar' adjusted for OpenACC privatization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc_nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
> -    ! { dg-note {variable 'char\.[0-9]+' adjusted for OpenACC privatization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc_nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop }
> +    ! { dg-note {variable 'char\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: artificial} "" { target *-*-* } l_loop$c_loop }
>      do i = 1, 15
>        scalar(i:i) = achar(ichar('A') + i)
>      end do
-----------------
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

  reply	other threads:[~2022-10-18 14:46 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 [this message]
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 ` amdgcn: Use FLAT addressing for all functions with pointer arguments [PR105421] (was: [PATCH] [og12] amdgcn: Use FLAT addressing for all functions with pointer arguments) Thomas Schwinge
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=878rldur4g.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).