public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Frederik Harwath <frederik@codesourcery.com>, <frederik@harwath.name>
Cc: <gcc-patches@gcc.gnu.org>, <tdevries@suse.de>, <mjambor@suse.cz>,
	Andrew Stubbs <ams@codesourcery.com>,
	Julian Brown <julian@codesourcery.com>,
	Tobias Burnus <tobias@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support
Date: Sat, 21 Dec 2019 23:01:00 -0000	[thread overview]
Message-ID: <87bls1wd4x.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <1c2e2d57-31ce-8e4d-c8b9-c2fbc7091e86@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

Hi Frederik!

On 2019-12-20T17:46:57+0100, "Harwath, Frederik" <frederik@codesourcery.com> wrote:
>> | 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'.
>> Frederik, please work on that, also try to move function definitions etc.
>> into appropriate places in case they aren't; ask if you need help.
>> That needs to be updated.
>
> Is it ok to do this in a separate follow-up patch?

Yes.  This doesn't affect anything but the libgomp-plugin interface.


>> > --- a/include/gomp-constants.h
>> > +++ b/include/gomp-constants.h
>> > @@ -178,6 +178,20 @@ enum gomp_map_kind
>> >=20=20
>> >  #define GOMP_DEVICE_ICV			-1
>> >  #define GOMP_DEVICE_HOST_FALLBACK	-2
>> > +#define GOMP_DEVICE_CURRENT		-3
>> [...]
>>
>> Not should if this should be grouped with 'GOMP_DEVICE_ICV',
>> 'GOMP_DEVICE_HOST_FALLBACK', for it is not related to there.
>>
>> [...]
>>
>> 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.
>> still wonder about that...  ;-)

> Changing the value of GOMP_DEVICE_ICV violates the following static asserts in oacc-parallel.c: [...]

Hmm, I didn't intend to suggest changing the 'GOMP_DEVICE_ICV' value,
which indeed can't/shouldn't be done.

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.

>> Maybe this 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.  ;-)


> Is it ok to commit the patch to trunk?

OK, thanks.  And then some follow-up/clean-up next year, also including
some of the open questions that I've snipped off here.


Grüße
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

  reply	other threads:[~2019-12-21 22:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03 16:51 [PATCH, og8] " Maciej W. Rozycki
2018-12-05 10:12 ` Chung-Lin Tang
2018-12-05 18:17   ` Maciej W. Rozycki
2018-12-10  9:06     ` Chung-Lin Tang
2018-12-20 14:25       ` Maciej W. Rozycki
2019-01-08 17:42 ` Thomas Schwinge
2019-10-07 18:41 ` Thomas Schwinge
2019-11-05 15:09   ` Harwath, Frederik
2019-11-14 15:41   ` [PATCH] " Frederik Harwath
2019-12-16 23:06     ` Thomas Schwinge
2019-12-17  9:39       ` Martin Jambor
2019-12-17  9:47       ` Andrew Stubbs
2019-12-20 17:11       ` Harwath, Frederik
2019-12-21 23:01         ` Thomas Schwinge [this message]
2019-12-22 22:20           ` Harwath, Frederik
2020-01-10 23:44           ` Thomas Schwinge
2020-01-30 16:14             ` Make OpenACC 'acc_get_property' with 'acc_device_current' work (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support) Thomas Schwinge
2020-02-03 12:16               ` Harwath, Frederik
2020-02-03 14:41               ` Make OpenACC 'acc_get_property' with 'acc_device_current' work Tobias Burnus
2020-01-16 16:03         ` [PATCH] Add OpenACC 2.6 `acc_get_property' support Thomas Schwinge
2020-01-20 14:20           ` Harwath, Frederik
2020-01-23 15:08             ` Thomas Schwinge
2020-01-24  9:36               ` Harwath, Frederik
2020-01-27 14:57         ` Fortran 'acc_get_property' return type (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support) Thomas Schwinge
2020-01-28 15:31         ` [PATCH] Add OpenACC acc_get_property support for AMD GCN Harwath, Frederik
2020-01-28 16:14           ` Andrew Stubbs
2020-01-29 10:10             ` Harwath, Frederik
2020-01-29 11:07               ` Andrew Stubbs
2020-01-29 11:47                 ` Harwath, Frederik
2020-01-29 17:58               ` Thomas Schwinge
2020-01-29 18:12                 ` Andrew Stubbs
2020-01-30  8:04                 ` Harwath, Frederik
2020-01-30 16:28               ` Thomas Schwinge
2020-01-30 16:54                 ` Andrew Stubbs
2020-01-31  9:32                   ` Thomas Schwinge
2020-01-31 12:32                 ` Harwath, Frederik
2020-01-31 14:49                   ` Thomas Schwinge
2020-04-29  9:19       ` [PATCH] Add OpenACC 2.6 `acc_get_property' support Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bls1wd4x.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=ams@codesourcery.com \
    --cc=frederik@codesourcery.com \
    --cc=frederik@harwath.name \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=julian@codesourcery.com \
    --cc=mjambor@suse.cz \
    --cc=tdevries@suse.de \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).