Hi all,

Jakub Jelinek wrote:
> On Sat, Jul 20, 2024 at 02:42:22PM -0600, Sandra Loosemore wrote:
>> This patch implements the libgomp runtime support for the dynamic
>> target_device selector via the GOMP_evaluate_target_device function.
> […]
>
> Now for kind, isa and arch traits in the target_device set this patch
> decides based on compiler flags used to compile some routine in libgomp.so
> or libgomp.a.
>
> While this can work in the (very unfortunate) GCN state of things where
> only exact isa match is possible (I really hope we can one day generalize
> it by being able to compile for a set of isas by supporting lowest
> denominator and patching the EM_* in the ELF header or something similar,
> perhaps with runtime decisions on what to do for different CPUs),

I think that can only work to some extend. LLVM has "gfx11-generic" 
which is compatible with gfx110{0,1,2,3,} and gfx115{0,1,2}, which at 
least helps a bit. For gfx10, it has gfx10-1-generic for gfx101{0,1,2,3} 
and gfx10-3-generic for gfx103[0-6] and gfx9-generic for gfx90{0,2,4,6,9,c}.

Thus, we could have versions which support a common subset, but we still 
need multiple libraries. And it needs to be implemented …

This sounds like a task for the GCN maintainer …

* * *

> deciding what to do based on how libgomp.a or libgomp.so.1 has been compiled for the
> rest is IMHO wrong.

I wonder whether we should do something like the following.

[The following is a mix between compile code and generated code, for illustrative
purpose.]

Inside the compiler do:

#ifndef ACCEL_COMPILER
intr = 0; if (targetm.omp.device_kind_arch_isa != NULL) r = 
targetm.omp.device_kind_arch_isa (omp_device_{kind,arch,isa}, val);

    if (dev_num && TREE_CODE (dev_num) == INTEGER_CST)
      {
        if (dev_num < -1 /* INVALID_DEVICE or nonconforming */)
          → 0
        if (dev_num == initial_device)
          → r
      }
<code gen>
      /* The '? :' condition is a compile time condition. */
      d = <dev_num> ? <dev_num> : omp_get_default_device ();
      if (d < -1)
        → 0
      else if (d == -1 || d == omp_get_initial_device ())
        → r
      else
        → GOMP_get_device_kind_arch_isa  (d, kind, arch, isa)
</codegen>
#else
    /* VARIANT 1: Assume that neither reverse offload nor nested target occurs. */
    →targetm.omp.device_kind_arch_isa  (kind, arch, isa)
    /* VARIANT 2 -
    d = <dev_num> ? <dev_num> : omp_get_default_device ();
    if (d == omp_get_device_num ())
      →targetm.omp.device_kind_arch_isa  (kind, arch, isa)
    else
      /* Cannot really do anything here - and as no nested target is permitted,
         use 'false'.  */
      → 0
#endif


* * *

And on the libgomp side GOMP_get_device_kind_arch_isa → plugin code.

And there:

(A) GCN:

kind and arch are clear. For ISA:

agent->device_isa + use existing isa_hsa_name() function (or likewise).

(B) Nvptx:

cuDeviceGetAttribute + CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR = 75 
and CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR = 76.

Example: sm_89 = (major) 8 and (minor) 9.

* * *

Does this sound sensible?

Tobias

PS: For the current host-offload GSoC task, we might eventually think of 
using cpuid on x86-64, i.e. gcc/config/i386/cpuid.h.

PS: RFC remains: Should 'sm_80' be true if the hardware/compilation is 
'sm_89' or not? Namely: Does 'sm_80' denote the capability or the 
specific hardware?

Regarding this topic, see also 
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662059.html