[Bug middle-end/105640] New: [OpenMP] Context selectors missing for PowerPC

[Bug middle-end/105640] New: [OpenMP] Context selectors missing for PowerPC

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

            Bug ID: 105640
           Summary: [OpenMP] Context selectors missing for PowerPC
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
            Target: powerpc64le,powerpc

Looking at https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.html
, I realized that we do now have OpenMP context selectors for PowerPC, which is
somewhat widely used with HPC and offloading and, thus, a relevant omission.

I think something like:
arch = powerpc, powerpc64, powerpc64le, rs64
  ?
kind = cpu
isa = ?
  maybe all values of RS6000_CPU (in rs6000-cpus.def)  excluding or not the
ones from arch
  = documentation wise, -mcpu= w/o 'native' (and possibly the values from arch)

Any other ISA flag?
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

Namely:
* TARGET_OMP_DEVICE_KIND_ARCH_ISA needs to be defined +
   associated rs6000_omp_device_kind_arch_isa be created
* t-omp-device be created
* libgomp.texi updated (cf. link above)
* a test to – or eqiuvalent:
    gcc/testsuite/c-c++-common/gomp/declare-variant-11.c

[Bug target/105640] [OpenMP] Context selectors missing for PowerPC

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It isn't implemented on anything but x86, nvptx and gcn.
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/threads.html#02066
has some more details.
aarch64 would be another HPC related target.

[Bug target/105640] [OpenMP] Context selectors missing for PowerPC

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And no, t-omp-device isn't needed, that one is solely for targets that can be
used for offloading.  i386 has it because of the intelmic offloading.

[Bug target/105640] [OpenMP] Context selectors missing for PowerPC

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'll also cite my response in
https://mailman.openmp.org/mailman/private/omp-lang/2020/016879.html

"The rationale for not using sm_XX for arch is that at least users of
compilers that target more than one CPU or GPU architecture should be able
to distinguish not just between different architectures of one kind of CPU
(or GPU etc.), but also in between them, furthermore e.g. for ISA there
could be overlaps in the names, not all instruction set architecture
extensions have unique names, so if e.g. (made up) both picochip and
mmix call some of their instruction set architecture extensions v1.0, v1.1
and v1.2, the user is able to distinguish, by writing
device={arch(picochip),isa(v1.1)}
or
device={arch(mmix),isa(v1.1)}
Both arch and isa are fuzzy terms, isa even stands for instruction set
ARCHITECTURE.
The only hint the specification gives is that the scoring order is
kind, arch, isa
and so IMNSHO we should treat kind (is this cpu, gpu or fpga (or
host/nohost)) as the hierarchically highest category, then the division into
major cpu (or gpu or fpga) architectures and as the third level the even
smaller details.
If one uses just sm_XX for arch and cc_XX for isa, there is no way to say
that you actually have in mind the nvidia GPGPUs, as opposed to some other
GPGPU that happens to call some instruction set or part of it sm_XX.

So, I'd prefer if the arch names were something clearly unique, that there
is no other cpu/gpu/fpga with such a name or that it is obvious what kind
of arch it is for most users.  People working with nvidia GPGPUs will know
what sm_XX means, but people that only do CPU programming on say mainframe
will know the different isas of their architecture but not have an idea
what sm_XX could mean.  So nvptx looks like a better name to me, that
includes the nvidia part as well as the ptx that is significant, because
nvidia could in 10-20 years use completely incompatible architecture, or
the gpus from 10-20 years ago weren't compatible either.

The border line is names in common use that both uniquely identify the
cpu/gpu/fpga major architecture/ABI, but also the architecture level.
E.g. power8 includes in the name both the major architecture (power) and the
ISA level.  Though, it doesn't include other important part of the ABI,
namely is this 32-bit or 64-bit, little-endian or big-endian and is it (when
on Linux) ELFv1 or ELFv2.  So, perhaps power8 is not the best arch (and what
would be isa in that case anyway), and we want powerpc to stand for any
powerpc-ish, powerpc32 for 32-bit big-endian, powerpc64 for 64-bit big-endian
and powerpc64le for 64-bit little-endian as arch and then use
power5/power6/power7/power8/power9 etc. as isa.  Though, maybe instead
powerpc should stand for 32-bit powerpc and powerpc32 shouldn't exist,
perhaps more people will understand it that way.
Another example is s390 (System-Z), some of the ISA levels at least include
the z, but it isn't sufficiently unique IMHO, so z900 or z196 aren't the
best arch candidates, but e.g. arch13 is even worse, that is always wrong
for arch, because you can have arch13 on many CPUs.
So, I think s390 (for 31-bit) and s390x for (64-bit), unsure if something
for both, are better arch names, and keep z900, z196, zEC12, z15 etc. as
isa names.

The context selectors can contain vendor too, but that is in implementation
and at least to me is about the software stack (i.e. software vendor which
can but doesn't have to be the corresponding hw vendor), rather than vendor
of some hw (and what exactly, many devices contain parts from many different
vendors).

We don't right now have anything to identify the operating system (Linux,
Windows, MacOS, FreeBSD, AIX, VMS, ...), if we want that, I think that
would go into implementation."

[Bug target/105640] [OpenMP] Context selectors missing for PowerPC

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What does LLVM implement?
Either I'm looking at a wrong place, or at least their testsuite coverage for
this is non-existing.
I see no sse nor avx substrings in clang/test/OpenMP/* (except for sse2020
which looks to stand for non-existent), no power substrings, ppc only combined
with that sse2020.

[Bug target/105640] [OpenMP] Context selectors missing for PowerPC

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105640

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Regarding LLVM, I have no idea, but doing some searching, I do see:

* clang/test/OpenMP/declare_variant_clauses_ast_print.cpp:
//PRINT: #pragma omp declare variant(foo_v2) match(construct={dispatch},
device={arch(ppc)}) adjust_args(need_device_ptr:AAA)

* clang/test/OpenMP/declare_variant_messages.c:
#pragma omp begin declare variant match(device={isa(sse2020), arch(ppc)})

 * * *

Otherwise, the following archs are supported according to
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def:

__OMP_TRAIT_PROPERTY(device, arch, arm)
__OMP_TRAIT_PROPERTY(device, arch, armeb)
__OMP_TRAIT_PROPERTY(device, arch, aarch64)
__OMP_TRAIT_PROPERTY(device, arch, aarch64_be)
__OMP_TRAIT_PROPERTY(device, arch, aarch64_32)
__OMP_TRAIT_PROPERTY(device, arch, ppc)
__OMP_TRAIT_PROPERTY(device, arch, ppcle)
__OMP_TRAIT_PROPERTY(device, arch, ppc64)
__OMP_TRAIT_PROPERTY(device, arch, ppc64le)
__OMP_TRAIT_PROPERTY(device, arch, x86)
__OMP_TRAIT_PROPERTY(device, arch, x86_64)
__OMP_TRAIT_PROPERTY(device, arch, amdgcn)
__OMP_TRAIT_PROPERTY(device, arch, nvptx)
__OMP_TRAIT_PROPERTY(device, arch, nvptx64)


It is not quite clear what is permitted as ISA. That file has:

OMP_TRAIT_PROPERTY(device_isa___ANY, device, device_isa,
                   "<any, entirely target dependent>")

and later in the .cc code:

    // We overwrite the isa trait as it is actually up to the OMPContext hook
to
    // check the raw string(s).
    if (Property == TraitProperty::device_isa___ANY)
      IsActiveTrait = llvm::all_of(VMI.ISATraits, [&](StringRef RawString) {
        return Ctx.matchesISATrait(RawString);

which in turn uses:

bool TargetOMPContext::matchesISATrait(StringRef RawString) const {
  auto It = FeatureMap.find(RawString);
  if (It != FeatureMap.end())
    return It->second;
  if (!FeatureValidityCheck(RawString))
    DiagUnknownTrait(RawString);
  return false;

which in turn is initialized via

void ASTContext::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
                                       const FunctionDecl *FD) const {
  if (FD)
    getFunctionFeatureMap(FeatureMap, GlobalDecl().getWithDecl(FD));
  else
    Target->initFeatureMap(FeatureMap, getDiagnostics(),
                           Target->getTargetOpts().CPU,
                           Target->getTargetOpts().Features);
}

In my understanding, that matches:
  clang/lib/Basic/Targets/NVPTX.h:    Features[CudaArchToString(GPU)] = true;
  clang/lib/Basic/Targets/NVPTX.h:    Features["ptx" +
std::to_string(PTXVersion)] = true;
where the former comes from
  static const CudaArchToStringMap arch_names
in clang/lib/Basic/Cuda.cpp

and for PowerPC, there is clang/lib/Basic/Targets/PPC.cpp