[Openmp-commits] [PATCH] D135162: [OPENMP] New api ompx_get_team_procs(devid)

[Greg Rodgers via Phabricator via Openmp-commits]

gregrodgers added a comment.

See answer to inline comment.



================
Comment at: openmp/libomptarget/include/device.h:325
+  /// for AMD, this is number of CUs. Field used by ompx_get_team_procs(devid).
+  int32_t TeamProcs;
 
----------------
jdoerfert wrote:
> gregrodgers wrote:
> > jdoerfert wrote:
> > > It's unclear why we need to store this in two places, the plugins and here. Other device data only lives in the plugins, this should too.
> > This is the value on the host DeviceTy that the getter and setter access.  The getter is for the new external api ompx_get_team_procs(devid).   The setter is called when the device is initialized and gets the value to set from the plugin which now stores the value in the DeviceData. 
> But why do we need to store it in the plugin and here? No other information, e.g., max num threads, is stored twice. This just copies the value from the plugin once, which seem to provide little benefit.
"No other information is stored twice"

Not exactly.  I tried to follow the mechanics of the omp_get_num_devices API as close as possible.   The plugin API __tgt_rtl_number_of_devices returns DeviceRTL.getNumbofDevices and initializes the PM->Devices vector in the plugin manager (outside the plugin) during initialization.
Similarly the new plugin API __tgt_rtl_number_of_team_procs returns the value stored in the plugin at initialization which is also stored in the PM.  I don't understand why there is a lock in omp_get_num_devices around access to PM,  but I copied the lock in ompx_get_team_procs.  I was just trying to be consistent with an existing API. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135162