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
