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

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

Hi Thomas, Happy New Year,

On 2018/12/19 5:03 AM, Thomas Schwinge wrote:
>> +
>> +  if (!dev->openacc.async.asyncqueue[async])
>> +    {
>> +      dev->openacc.async.asyncqueue[async] = dev->openacc.async.construct_func ();
>> +
>> +      if (!dev->openacc.async.asyncqueue[async])
>> +	{
>> +	  gomp_mutex_unlock (&dev->openacc.async.lock);
>> +	  gomp_fatal ("async %d creation failed", async);
>> +	}
> That will now always fail for host fallback, where
> "host_openacc_async_construct" just always does "return NULL".
> 
> Actually, if the device doesn't support asyncqueues, this whole function
> should turn into some kind of no-op, so that we don't again and again try
> to create a new one for every call to "lookup_goacc_asyncqueue".
> 
> I'm attaching one possible solution.  I think it's fine to assume that
> the majority of devices will support asyncqueues, and for those that
> don't, this is just a one-time overhead per async-argument.  So, no
> special handling required in "lookup_goacc_asyncqueue".

> --- a/libgomp/oacc-host.c
> +++ b/libgomp/oacc-host.c
> @@ -212,7 +212,8 @@ host_openacc_async_queue_callback (struct goacc_asyncqueue *aq
>   static struct goacc_asyncqueue *
>   host_openacc_async_construct (void)
>   {
> -  return NULL;
> +  /* We have to return non-NULL here, but it's OK to use a dummy.  */
> +  return (struct goacc_asyncqueue *) -1;
>   }

I'm not sure I understand the meaning of this? Is there any use to segfaulting somewhere else
due to this 0xffff... pointer?

A feature of a NULL asyncqueue should mean that it is simply synchronous, however this does somewhat
conflict with the case of async.construct_func() returning NULL on error...

Perhaps, again using an explicit success code as the return value (and return asyncqueue using
an out parameter)?

Chung-Lin