[Openmp-commits] [PATCH] D50522: [OpenMP][libomptarget] Bringing up to spec with respect to OMP_TARGET_OFFLOAD env var

[Jonas Hahnfeld via Phabricator via Openmp-commits]

Hahnfeld added a comment.

In https://reviews.llvm.org/D50522#1194113, @AlexEichenberger wrote:

> In https://reviews.llvm.org/D50522#1194100, @Hahnfeld wrote:
>
> > As discussed in there I don't see that `DEFAULT` means `MANDATORY` only iff there was a successful offload. From TR7, page 610, lines 17/18:
> >
> > > The DEFAULT value specifies that when one or more target devices are available, the runtime
> > >  behaves as if this environment variable is set to MANDATORY [...]
>
>
> The question is how we define "available." IMO, it means success of first command. Happy to reconsider, I think most of our users are fine with success of first command


You are right, "available" is not defined in the standard. I've always though of "plugged into the system", ie all devices that are visible to the CUDA runtime. That would match the current implementation of `omp_get_num_devices` which is defined to return "the number of available target devices".
Actually this behaviour would be important for us as we have our GPUs configured exclusively. So when there is already a process running all other users get a runtime error. In that case it would be very helpful to have `libomptarget` abort the program.

>> Another remark from https://reviews.llvm.org/D44522: I think we need to handle API methods as well.
> 
> I am all for using the suggested __kmpc_get_target_offload function, which is implemented. If we do so, we will be depending on a definition in kmp.h. Do we want a redundant definition of the
> 
>   enum kmp_target_offload_kind {
>     tgt_disabled = 0,
>     tgt_default = 1,
>     tgt_mandatory = 2
>   };
> 
> 
> I assume we want to do that, as we don't want to include kmp.h in libomptarget.

Yes, https://reviews.llvm.org/D44522 also had that.


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D50522