[PATCH] Add OpenACC 2.6 `acc_get_property' support

Thomas Schwinge thomas@codesourcery.com
Fri Jan 10 23:44:00 GMT 2020


Hi!

On 2019-12-21T23:02:38+0100, I wrote:
> On 2019-12-20T17:46:57+0100, "Harwath, Frederik" <frederik@codesourcery.com> wrote:
>>> > --- a/include/gomp-constants.h
>>> > +++ b/include/gomp-constants.h

>>> > +#define GOMP_DEVICE_CURRENT		-3

>>> Should this actually get value '-1' instead of '-3'?  Or, is the OpenACC
>>> 'acc_device_t' code already paying special attention to negative values
>>> '-1', '-2'?  (I don't think so.)

>>> | Also, 'acc_device_current' is a libgomp-internal thing (doesn't interface
>>> | with the compiler proper), so strictly speaking 'GOMP_DEVICE_CURRENT'
>>> | isn't needed in 'include/gomp-constants.h'.  But probably still a good
>>> | idea to list it there, in this canonical place, to keep the several lists
>>> | of device types coherent.

>>> I still wonder about that...  ;-)

> I still think that 'GOMP_DEVICE_CURENT' should get value '-1' (and
> probably be rename 'GOACC_DEVICE_CURRENT' to make more obvious that it's
> not related to the 'GOMP_DEVICE_*' ones), but we shall have a look at
> that later (before GCC 10 release); that's libgomp/OpenACC-internal,
> doesn't affect anything else.

That's still pending.  Recently,
<https://github.com/OpenACC/openacc-spec/issues/256> "Missing definition
for acc_device_current" got filed; let's (also/first) watch/wait what
comes out of that.


Also pending is the 'libgomp/plugin/plugin-gcn.c' update; Frederik is
working on that.


A few other (minor) open issue we shall discuss at some later point in
time.


>>> | Before Frederik starts working on integrating this into GCC trunk, do you
>>> | (Jakub) agree with the libgomp plugin interface changes as implemented by
>>> | Maciej?  For example, top-level 'GOMP_OFFLOAD_get_property' function in
>>> | 'struct gomp_device_descr' instead of stuffing this into its
>>> | 'acc_dispatch_t openacc'.  (I never understood why the OpenACC functions
>>> | need to be segregated like they are.)
>>>
>>> Jakub didn't answer, but I now myself decided that we should group this
>>> with the other OpenACC libgomp-plugin functions, as this interface is
>>> defined in terms of OpenACC-specific stuff such as 'acc_device_t'.

Done.  This also means that we don't anymore need (stub) implementations
in the libgomp plugins that don't implement OpenACC support.


>>> Maybe [stuff] should move from 'include/gomp-constants.h' to
>>> 'libgomp/oacc-int.h'.  I'll think about that again, when I'm awake again
>>> tomorrow.  ;-)
>>
>> Have you made up your mind yet? :-)
>
> Still sleepy.  ;-)

Done.  In the end, 'libgomp/libgomp-plugin.h' is the place to be, as that
defines, well, the libgomp plugin interface.  ;-)


See attached "OpenACC 'acc_get_property' cleanup"; committed to trunk in
r280150.


Grüße
 Thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OpenACC-acc_get_property-cleanup.trunk.patch
Type: text/x-diff
Size: 21012 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20200110/005f0a1c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 658 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20200110/005f0a1c/attachment.sig>


More information about the Gcc-patches mailing list