[Openmp-commits] [PATCH] D124652: [OpenMP] [OMPT] [amdgpu] [5/8] Implemented device init/fini/load callbacks

Johannes Doerfert via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Mar 22 17:26:50 PDT 2023


jdoerfert added a comment.

Read the large comment first, this might also result in changes to other patches. The design should match nextgen and it should be a proper part of it, not some attached afterthought.



================
Comment at: openmp/libomptarget/include/ompt_device_callbacks.h:149
+  /// Documentation based on omp-tools
+  static const char *Documentation;
 };
----------------
I don'n understand why there are so many static members and functions everywhere, but alas.


================
Comment at: openmp/libomptarget/plugins-nextgen/common/OMPT/OmptCallback.cpp:30
+/// Array denoting the devices
+static OmptDeviceTy *Devices = nullptr;
+
----------------
Now there are static members, and static non members, I mean, why?


================
Comment at: openmp/libomptarget/plugins-nextgen/common/OMPT/OmptCallback.cpp:29
+/// Array denoting the devices
+static OmptDeviceTy *Devices = 0;
+
----------------
mhalk wrote:
> jplehr wrote:
> > Probably better use `nullptr` here.
> Done.
Also above?


================
Comment at: openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp:366
+#ifdef OMPT_SUPPORT
+  OmptDeviceCallbacks.prepareDevices(Plugin.getNumDevices());
+  OmptDeviceCallbacks.OmptCallbackDeviceInitialize(
----------------
So, these OmptDevices are stored in 4 or so static members mostly inside OmptDeviceCallbacksTy, and initialized via a member of OmptDeviceCallbacks which is a global object that flies around.

This is really too much.

Let's approach this differently:
One OmptDeviceTy per device of a plugin, right?
If so, make one such object a member of GenericDeviceTy, all that array stuff and 4 functions can be removed, init and deinit are performed via constructor/destructor or init/deinit of the parent.
Funnily, once you do that, the entire `OmptDeviceTy` code would be moot and all you really put into GenericDeviceTy::(de)init is one conditional to check and call the callback.
You can even make a variadic macro that checks the callback and calls it, forwarding the args, which will simplify the pattern to sth like:
```
ompt_callback(device_initialize, DeviceNum, Type, reinterpret_cast<ompt_device_t *>(this), doLookup, Documentation);
```

Then, why do we need OmptDeviceCallbacksTy in the first place?
Shouldn't the callbacks be close to their invocation, e.g., in GenericDeviceTy, etc.




================
Comment at: openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp:470-473
+      DeviceId, nullptr /* FileName */, 0 /* File Offset */,
+      nullptr /* VmaInFile */, Bytes /* ImgSize */,
+      InputTgtImage->ImageStart /* HostAddr */, nullptr /* DeviceAddr */,
+      0 /* FIXME: ModuleId */);
----------------
mhalk wrote:
> jplehr wrote:
> > Idk if there is a guideline for it, but I personally would prefer to have this read as `/* FileName= */ nullptr, ...`
> I would be interested in that, too -- in the previous version of these files it was this (`nullptr /* FileName= */,`) way.
> But TBH I don't find that intuitively either, i.e. I would also prefer your proposal.
> Any other thoughts or info on this would be appreciated.
`/* Name */ Value`, which is hopefully what the rest of the code does.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124652/new/

https://reviews.llvm.org/D124652



More information about the Openmp-commits mailing list