This looks OK for us (HPE). CCE does use the entry point that this patch will deprecate, and we'll probably keep it around in our runtime, so as long as it is not repurposed and changed in the future than it should not affect us. We will plan to use the new interface for target nowait once it is in.

LG.

Is the target to get this merged in for LLVM 16? Does the VGPU implementation provide a way to support OMPT callbacks for various constructs (parallel, worksharing, barriers, etc.)?

Looks good.

@tianshilei1992 Can you explain a bit more what is the motivation here? Does requiring a new entry point rather than changing the interface for a pre-existing entry point create problems? The Cray compiler doesn't use libomptarget, but it does use the interface. It is also designed to support interoperability with other LLVM-based compilers, which may be based on a newer version of LLVM. Backwards compatibility with the libomptarget interface is needed for that to work (not necessary for the plugins).

LGTM.

LGTM.

LGTM.

LGTM.

Looks good to me.

This looks good to me. Is there a particular version of gdb that this plugin depends on? I didn't see that documented.

I don't have commit access. Can someone commit this for me? Thanks.

I think I've addressed the first set of comments. I added a TODO comment for the OMP IRBuilder (HPE has not implemented this). I also added a diagnostic error message for the case of a mutexinoutset being specified in a depend clause on the taskwait directive, as this is specifically disallowed. Can reviewers take another look and let me know if this looks ready?

Thanks. This LGTM.

What happens for a teams construct? The implicit tasks in that case are all initial tasks. Should this Data->Team->Delete() apply there as well, or only for the implicit parallel region for the whole program?

Updated comments, added TODO for handing extended taskwait directive in the OpenMPIRBuilder, and added semantic check that 'mutexinoutset' should not be specified in the 'depend' clause on 'taskwait'.

There still exists a restriction that the loop variable must not be threadprivate in OpenMP 5.1. See Canonical Loop Nest restrictions, p125, line 7:

In D91944#2414364, @jdoerfert wrote:

This looks close to an OpenMP 5.0 implementation. I left comments inlined.

We need tests that show how non-selected alternatives *do not* impact the program. As an example, a template instantiation inside of a non-selected alternative is not actually performed.

We also need test with ill-formed metadirectives.

I don't have commit access. @jdoerfert, please commit the change if you think it's ready. Thanks.

Marking the "begin/end declare variant" feature as 'done' in the 5.1 table.

I don't believe I have commit permissions on this. @ABataev, can you commit this? Thanks.