Re: [PATCH 2/6, OpenACC, libgomp] Async re-work, oacc-* parts

[Chung-Lin Tang <chunglin_tang@mentor.com>]

On 2018/12/17 9:52 PM, Thomas Schwinge wrote:
> Hi Chung-Lin!
> 
> On Fri, 14 Dec 2018 22:52:44 +0800, Chung-Lin Tang <chunglin_tang@mentor.com> wrote:
>> On 2018/12/14 10:17 PM, Thomas Schwinge wrote:
>>> On Tue, 25 Sep 2018 21:10:47 +0800, Chung-Lin Tang <chunglin_tang@mentor.com> wrote:
>>>> --- a/libgomp/oacc-async.c
>>>> +++ b/libgomp/oacc-async.c
>>>
>>>> +attribute_hidden struct goacc_asyncqueue *
>>>> +lookup_goacc_asyncqueue (struct goacc_thread *thr, bool create, int async)
>>>> +{
>>>> +  /* The special value acc_async_noval (-1) maps to the thread-specific
>>>> +     default async stream.  */
>>>> +  if (async == acc_async_noval)
>>>> +    async = thr->default_async;
>>>> +
>>>> +  if (async == acc_async_sync)
>>>> +    return NULL;
>>>> +
>>>> +  if (async < 0)
>>>> +    gomp_fatal ("bad async %d", async);
>>>
>>> To make this "resolve" part more obvious, that is, the translation from
>>> the "async" argument to an "asyncqueue" array index:
>>>
>>>> +  if (!create
>>>> +      && (async >= dev->openacc.async.nasyncqueue
>>>> +	  || !dev->openacc.async.asyncqueue[async]))
>>>> +    return NULL;
>>>> +[...]
>>>
>>> ..., I propose adding a "async2id" function for that, and then rename all
>>> "asyncqueue[async]" to "asyncqueue[id]".
>>
>> I don't think this is needed. This is the only place in the entire runtime that
>> does asyncqueue indexing, adding more conceptual layers of re-directed indexing
>> seems unneeded.
> 
> It makes the code better understandable?  Or, curious, why do you think
> that the translation from an OpenACC async-argument to an internal
> asyncqueue ID should not be a separate function?

Because the index is (1) not used elsewhere; nor supposed to really, lookup_goacc_asyncqueue()
is intended to be the centralized place for looking up async queues.
and (2) the special async number case handling here is really short, creating another
conceptual index-redirecting in the code feels like over-engineering.

>> I do think the more descriptive comments are nice though.
> 
> 
>>> And, this also restores the current trunk behavior, so that
>>> "acc_async_noval" gets its own, separate "asyncqueue".
>>
>> Is there a reason we need to restore that behavior right now?
> 
> Because otherwise that's a functional change ("regression") from the
> current GCC trunk behavior, which I wouldn't expect in a re-work.

Okay, but do take note that the acc_get/set_default_async is part of the upstreaming too.
The behavior change is due to that new 2.5 functionality, not really because I arbitrarily changed things.

Thanks,
Chung-Lin