[PATCH] libgomp: Add OMPD process functions and datatypes.

[y2s1982 .]

Hello

On Wed, Jul 8, 2020 at 5:08 AM Jakub Jelinek <jakub@redhat.com> wrote:

> On Tue, Jul 07, 2020 at 02:52:37PM -0400, y2s1982 . via Gcc-patches wrote:
> > I have re-read the documentation trying to find a different solution.
> > In particular, ompd_device_initialize states that
> > ompd_device_t kind, ompd_size_t sizeof_id, and void *id represents
> > a device identifier. To dig further, I read up on the ompd_device_t. A
> > passage from ompd_device_t says that the OMPD library and a tool that
> uses
> > it must agree on the format of the object that is passed.
> > It also says that ompd_device_t is a pointer to where the device
> identifier
> > is stored and the size of the device identifier. I am not sure how this
> > works to ompd_device_initialize as those two information seems to be
> > supplied separately: *id and sizeof_id. In fact, ompd-type.h provides 4
> > examples, 2 of which are host and cuda, and they all simply contain
> unique
> > numerical values.  So does this mean that I should just decide on what
> the
> > library and tool will use for device id data type and simply stick to it?
> >
> > Otherwise, Is it possible to know the proper data type to cast the void
> *id
> > based on the device type (host/cuda)?
>
> Looking at libompd, it ignores sizeof_id completely and saves id (the
> pointer) in its device context, but doesn't ever do anything with it, so
> effectively ignores it completely.
>
> I think starting with devices it not a good idea, just return failure from
> ompd_device_initialize for now and get back to it much later, when
> handling of parallel, host teams, task etc. is all done.
> Because communicating with devices will need also communication with the
> libgomp plugins.
>

Thank you for the guidance. I have uploaded an updated patch where
ompd_device_initialize() ultimately returns an error. I have also added
FIXME
for future planning.

Tony

>
>         Jakub
>
>