LGTM. Thanks!

I would keep it simple:

Fixing issues

Looks good to me now. Thanks!

Removing unused function

Rebasing

Fixing comments.

Simplifying patch.

Please also document the new envar in openmp/docs/design/Runtimes.rst, in the Libomptarget Environment Variables section.

Updating patch to initial version. We make sure in libomptarget that the device is initialized (ready) when printing its information. Together with https://reviews.llvm.org/D148178, it should fix the llvm-omp-device-info command.

Fixed format

Fixed reviewers' comments

Fixing review comments and other improvements.

Examples of llvm-omp-device-info in AMDGPU and NVIDIA devices:

Added support for CUDA plugin and improved generic code.

Updated patch removing the error return from AsyncInfoWrapperTy::finalize().

Example of a device info printing for a AMDGPU device:

8dad7f495302b5f2cd186dcc1cdd76874c80958a

This patch is to support setting thread_limit clause to -1? Or is it for another case? If I'm not wrong, the OpenMP standard specifies that the value for thread_limit clause should be positive.

Removed unrelated change

There is also the option to auto initialize the devices at the plugin level when GenericPluginTy::getDevice(N) is called and device N is in a uninitialized state. In my opinion, that would be the safest option and would cover all cases. But it will require implementing a similar mechanism from libomptarget level to guarantee the device creation and initialization is tread-safe and serialized (i.e., std::call_once in libomptarget).

The initial patch should fix the crash for the llvm-omp-device-info case, or any other case calling __tgt_print_device_info. I saw lazy initialization of devices in other API calls and tried to reproduced the same behavior. Anyway, initializing them explicitly from the tool seems more clean, so I just updated the patch with it.

Explicitly initializing devices from llvm-omp-device-info tool.

This patch is still missing a test.

Removing most references to NextGen plugins and assuming this is the only plugin implementation available. Now it should be consistent with D142820. Fixing format too.

In D144975#4161931, @jhuber6 wrote:

Should we bother calling them nextgen considering that they will be the only gen in two weeks?

Already fixed in D145105.

LGTM

LGTM

The locking of mapped host buffers is disabled by default. Can be enabled through the LIBOMPTARGET_LOCK_MAPPED_HOST_BUFFERS envar. The envar accepts boolean values (on/off) and a special option:

• off: Do not lock mapped host buffers (default).
• on: Lock mapped host buffers automatically, but do not report lock failures if the plugin fails to lock them.
• mandatory: Lock mapped host buffers automatically and treat locking failures in the plugins as fatal errors. This option may be useful for debugging purposes.

LGTM

Fix debug print

Fixing bug. Now complex reduction tests work.

Fix format.

Changes:

• Fixing comments.
• Re-writing the PinnedAllocationMapTy functions to be clearer and easier to read.
• Renaming RTL API functions.
• Disable automatic locking of mapped host buffers by default. Can be enabled by setting LIBOMPTARGET_LOCK_MAPPED_HOST_BUFFERS envar.
• Although the previous envar is not set, mapped buffers that were externally locked (e.g, the app allocating HSA memory) are registered into the plugin's map and we use a single-step asynchronous HSA memory transfer. (@ye-luo)