From: Cesar Philippidis <cesar@codesourcery.com>
To: Nathan Sidwell <nathan@acm.org>, Jakub Jelinek <jakub@redhat.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: openacc reference reductions
Date: Fri, 08 Apr 2016 14:46:00 -0000 [thread overview]
Message-ID: <5707C43A.4050800@codesourcery.com> (raw)
In-Reply-To: <5707BCB5.2050607@acm.org>
On 04/08/2016 07:14 AM, Nathan Sidwell wrote:
> On 04/08/16 00:40, Jakub Jelinek wrote:
>
>>> +/* OpenACC parallel reductions need a present_or_copy clause to ensure
>>> + that the original variable used in the reduction gets updated on
>>> + the host. Scan the list of clauses for reduction so that any
>>> existing
>>> + data clause can be adjusted if necessary. */
>>> + if (region_type == ORT_ACC_PARALLEL)
>>> + {
>>> + for (c = *list_p; c; c = OMP_CLAUSE_CHAIN (c))
>>> + {
>>> + tree decl = NULL_TREE;
>>> +
>>> + if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_REDUCTION)
>>> + continue;
>>> +
>>> + decl = OMP_CLAUSE_DECL (c);
>>> + omp_add_variable (ctx, decl, GOVD_REDUCTION);
>>> + }
>>> + }
>>> +
>>
>> And this looks also wrong, why?
>
> And besides, won't it break
> #pragma acc parallel firstprivate (x) reduction(+:x)
> {...}
This would become an error. But we'd still allow stuff like
#pragma acc parallel firstprivate(x)
#pragma acc loop reduction(+:x)
> which the openacc guys at GTC indicated they didn't want to disallow
> (without further thinking).
I'm not sure what the purpose of a firstprivate parallel reduction is
anyway. By definition, the final result of a parallel reduction isn't
available until the end of the parallel region. And if the value is
firstprivate, the final result can never be utilized. That seems like a
candidate for an error to me.
> It seems to me the interaction of reduction and data copying at a
> parallel is still not sufficiently well defined.
Tom and I were pushing to make parallel reductions imply copy (or
present_or_copy in openacc 2.0). Did that fall through?
Cesar
next prev parent reply other threads:[~2016-04-08 14:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 15:14 Cesar Philippidis
2016-02-09 15:33 ` Nathan Sidwell
2016-02-09 16:17 ` Cesar Philippidis
2016-02-22 15:34 ` Cesar Philippidis
2016-02-22 16:23 ` Nathan Sidwell
2016-04-06 1:54 ` Cesar Philippidis
2016-04-06 14:23 ` Jakub Jelinek
2016-04-06 20:21 ` Cesar Philippidis
2016-04-07 9:57 ` Jakub Jelinek
2016-04-08 4:34 ` Cesar Philippidis
2016-04-08 7:41 ` Jakub Jelinek
2016-04-08 7:44 ` Jakub Jelinek
2016-04-08 14:14 ` Nathan Sidwell
2016-04-08 14:21 ` Jakub Jelinek
2016-04-08 14:46 ` Cesar Philippidis [this message]
2016-04-08 14:49 ` Nathan Sidwell
2016-04-08 14:35 ` Cesar Philippidis
2016-04-08 15:30 ` Jakub Jelinek
2021-04-26 10:35 ` [OpenACC] Don't compile libgomp testcases with '-w' (was: openacc reference reductions) 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=5707C43A.4050800@codesourcery.com \
--to=cesar@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=nathan@acm.org \
/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).