[all-commits] [llvm/llvm-project] 9da61a: [OpenMP] Emit offloading entries for indirect targ...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9da61aed751ea6a51e7fa2e970de896d3cc27791
      https://github.com/llvm/llvm-project/commit/9da61aed751ea6a51e7fa2e970de896d3cc27791
  Author: Joseph Huber <jhuber6 at vols.utk.edu>
  Date:   2023-08-24 (Thu, 24 Aug 2023)

  Changed paths:
    M clang/lib/CodeGen/CGOpenMPRuntime.cpp
    M clang/lib/CodeGen/CGOpenMPRuntime.h
    M clang/lib/CodeGen/CodeGenModule.cpp
    A clang/test/OpenMP/target_indirect_codegen.cpp
    M llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
    M llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

  Log Message:
  -----------
  [OpenMP] Emit offloading entries for indirect target variables

OpenMP 5.1 allows emission of the `indirect` clause on declare target
functions, see https://www.openmp.org/spec-html/5.1/openmpsu70.html#x98-1080002.14.7.
The intended use of this is to permit calling device functions via their
associated host pointer. In order to do this the first step will be
building a map associating these variables. Doing this will require the
same offloading entry handling we use for other kernels and globals.

We intentionally emit a new global on the device side. Although it's
possible to look up the device function's address directly, this would
require changing the visibility and would prevent us from making static
functions indirect. Also, the CUDA toolchain will optimize out unused
functions and using a global prevents that. The downside is that the
runtime will need to read the global and copy its value, but there
shouldn't be any other costs.

Note that this patch just performs the codegen, currently this new
offloading entry type is unused and will be ignored by the runtime.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D157738