This is the mail archive of the
mailing list for the GCC project.
Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags"
- From: Thomas Schwinge <thomas at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>, Gergö Barany <gergo_barany at mentor dot com>
- Date: Wed, 19 Dec 2018 14:59:54 +0100
- Subject: Re: For OpenACC libgomp entry points, redefine the "int device" argument to "unsigned int flags"
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20181219133838.GA23305@tucnak>
On Wed, 19 Dec 2018 14:38:38 +0100, Jakub Jelinek <email@example.com> wrote:
> On Wed, Dec 19, 2018 at 01:46:06PM +0100, Thomas Schwinge wrote:
> > > Or, I had the idea that we could avoid that, instead continue using
> > > "GOMP_MAP_USE_DEVICE_PTR", and transmit the "if_present" flag through the
> > > "int device" argument of "GOACC_data_start" (making sure that old
> > > executables continue to function as before). For OpenACC, that argument
> > > is only ever set to "GOMP_DEVICE_ICV" or "GOMP_DEVICE_HOST_FALLBACK" (for
> > > "if" clause evaluating to "false"), so has some bits to spare for that.
> > > However, I've not been able to convince myself that this solution would
> > > be any much prettier than adding a new mapping kind... ;-)
> > Having thought about it some more, the idea doesn't actually seem so bad
> > anymore. :-) Just don't think of it as 'merging stuff into "int
> > device"', but rather 'for OpenACC libgomp entry points, redefine the "int
> > device" argument to "unsigned int flags"' -- see attached WIP (for GCC
> > trunk, testing).
> > Jakub, what do you think?
> So, what values you were passing in before as the argument? Just 0 or -1
> or something similar and nothing else? Just wondering if the change isn't
> an ABI change.
> In OpenMP we are passing a device number (from device clause), or -1, if
> no device clause was used and so ICV should be checked and -2 if it is
> if (false) and therefore should be always host fallback.
Right. For OpenACC, there's no "device" clause, so we only ever passed
in "GOMP_DEVICE_ICV" (default), or "GOMP_DEVICE_HOST_FALLBACK" ("if
(false)" clause). Therefore, the libgomp "resolve_legacy_flags" function
added to make sure that these two values (as used by old executables)
continue to work as before (with new libgomp). (And, we have to make
sure that no (new) "GOACC_FLAG_*" combination ever results in these
values; will document that.)
I'm currently doing a verification run of the libgomp testsuite (had one
detail botched up in the patch that I sent).
And just to make sure: as recently discussed in a different thread, we
don't have to support the case of new executables built that are
dynamically linking against old libgomp versions (where the latter won't
understand the new "flags" value "GOACC_FLAG_HOST_FALLBACK", would ignore