[Libomptarget] Rename `libomptarget.rtl.x86_64` to `libomptarget.rtl.host` #86868

jhuber6 · 2024-03-27T20:36:32Z

Summary:
All of these are functionally the same code, just compiled for separate
architectures. We currently do not expose a way to execute these on
separate architectures as the host plugin works using dlopen into the
same process, and therefore cannot possibly be an incompatible
architecture. (This could work with a remote plugin, but this is not
supported yet).

This patch simply renames all of these to the same thing so we no longer
need to check around for its varying definitions.

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on llvm#86868

Summary: This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on llvm#86971 llvm#86875 llvm#86868

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on llvm#86868

Summary: This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on llvm#86971 llvm#86875 llvm#86868

shiltian · 2024-03-29T22:33:03Z

openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt

@@ -14,36 +14,36 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
 endif()

 # Create the library and add the default arguments.
-add_target_library(omptarget.rtl.${machine} ${machine})
+add_target_library(omptarget.rtl.host ${machine})


can you just set a variable and then use it everywhere else?

The main reason for this change is in #87009 where I wanted to be able to enable these individually with a normal text string. E.g. -DLIBOMPTARGET_PLUGINS_TO_BUILD=cuda;amdgpu;host. This doesn't work if the name changes on the target since I wanted to make everything obey a standard naming convention.

I mean something like this:

set (host_target_name omptarget.rtl.host) ... target_link_libraries(${host_target_name} PRIVATE FFI::ffi_static)

Ah, well I figured it's all the same since it's the same name throughout the file. Not much difference between host_target_name and omptarget.rtl.host being put on every cmake argument.

If we want to rename it later, having in a variable would be easier though.

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on llvm#86868

Summary: This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on llvm#86971 llvm#86875 llvm#86868

jplehr

I think this change makes sense.

jplehr · 2024-04-10T21:07:28Z

openmp/libomptarget/plugins-nextgen/host/CMakeLists.txt

@@ -14,36 +14,36 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
 endif()

 # Create the library and add the default arguments.
-add_target_library(omptarget.rtl.${machine} ${machine})
+add_target_library(omptarget.rtl.host ${machine})


If we want to rename it later, having in a variable would be easier though.

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on llvm#86868

Summary: This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on llvm#86971 llvm#86875 llvm#86868

…host` Summary: All of these are functionally the same code, just compiled for separate architectures. We currently do not expose a way to execute these on separate architectures as the host plugin works using `dlopen` into the same process, and therefore cannot possibly be an incompatible architecture. (This could work with a remote plugin, but this is not supported yet). This patch simply renames all of these to the same thing so we no longer need to check around for its varying definitions.

llvmbot · 2024-04-26T18:33:10Z

@llvm/pr-subscribers-offload

Author: Joseph Huber (jhuber6)

Changes

Summary:
All of these are functionally the same code, just compiled for separate
architectures. We currently do not expose a way to execute these on
separate architectures as the host plugin works using dlopen into the
same process, and therefore cannot possibly be an incompatible
architecture. (This could work with a remote plugin, but this is not
supported yet).

This patch simply renames all of these to the same thing so we no longer
need to check around for its varying definitions.

Full diff: https://github.com/llvm/llvm-project/pull/86868.diff

2 Files Affected:

(modified) offload/plugins-nextgen/host/CMakeLists.txt (+20-20)
(modified) offload/src/CMakeLists.txt (+1-4)

diff --git a/offload/plugins-nextgen/host/CMakeLists.txt b/offload/plugins-nextgen/host/CMakeLists.txt
index 7da18ee278d498..6407f72e8db0a2 100644
--- a/offload/plugins-nextgen/host/CMakeLists.txt
+++ b/offload/plugins-nextgen/host/CMakeLists.txt
@@ -14,36 +14,36 @@ if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
 endif()
 
 # Create the library and add the default arguments.
-add_target_library(omptarget.rtl.${machine} ${machine})
+add_target_library(omptarget.rtl.host ${machine})
 
-target_sources(omptarget.rtl.${machine} PRIVATE src/rtl.cpp)
+target_sources(omptarget.rtl.host PRIVATE src/rtl.cpp)
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
   libomptarget_say("Building ${machine} plugin linked with libffi")
   if(FFI_STATIC_LIBRARIES)
-    target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi_static)
+    target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi_static)
   else()
-    target_link_libraries(omptarget.rtl.${machine} PRIVATE FFI::ffi)
+    target_link_libraries(omptarget.rtl.host PRIVATE FFI::ffi)
   endif()
 else()
   libomptarget_say("Building ${machine} plugin for dlopened libffi")
-  target_sources(omptarget.rtl.${machine} PRIVATE dynamic_ffi/ffi.cpp)
-  target_include_directories(omptarget.rtl.${machine} PRIVATE dynamic_ffi)
+  target_sources(omptarget.rtl.host PRIVATE dynamic_ffi/ffi.cpp)
+  target_include_directories(omptarget.rtl.host PRIVATE dynamic_ffi)
 endif()
 
 # Install plugin under the lib destination folder.
-install(TARGETS omptarget.rtl.${machine}
+install(TARGETS omptarget.rtl.host
         LIBRARY DESTINATION "${OFFLOAD_INSTALL_LIBDIR}")
-set_target_properties(omptarget.rtl.${machine} PROPERTIES
+set_target_properties(omptarget.rtl.host PROPERTIES
   INSTALL_RPATH "$ORIGIN" BUILD_RPATH "$ORIGIN:${CMAKE_CURRENT_BINARY_DIR}/.."
   POSITION_INDEPENDENT_CODE ON
   CXX_VISIBILITY_PRESET protected)
 
-target_include_directories(omptarget.rtl.${machine} PRIVATE
+target_include_directories(omptarget.rtl.host PRIVATE
                            ${LIBOMPTARGET_INCLUDE_DIR})
 
 if(LIBOMPTARGET_DEP_LIBFFI_FOUND)
-  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.${machine})
+  list(APPEND LIBOMPTARGET_TESTED_PLUGINS omptarget.rtl.host)
   set(LIBOMPTARGET_TESTED_PLUGINS
       "${LIBOMPTARGET_TESTED_PLUGINS}" PARENT_SCOPE)
 else()
@@ -52,36 +52,36 @@ endif()
 
 # Define the target specific triples and ELF machine values.
 if(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE TARGET_ELF_ID=EM_PPC64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_PPC64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
       LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="powerpc64le-ibm-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
        "powerpc64le-ibm-linux-gnu" "powerpc64le-ibm-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE TARGET_ELF_ID=EM_PPC64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_PPC64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
       LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="powerpc64-ibm-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
        "powerpc64-ibm-linux-gnu" "powerpc64-ibm-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE TARGET_ELF_ID=EM_X86_64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_X86_64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
       LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="x86_64-pc-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
        "x86_64-pc-linux-gnu" "x86_64-pc-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "aarch64$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE TARGET_ELF_ID=EM_AARCH64)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_AARCH64)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
       LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="aarch64-unknown-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
        "aarch64-unknown-linux-gnu" "aarch64-unknown-linux-gnu-LTO")
   set(LIBOMPTARGET_SYSTEM_TARGETS "${LIBOMPTARGET_SYSTEM_TARGETS}" PARENT_SCOPE)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "s390x$")
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE TARGET_ELF_ID=EM_S390)
-  target_compile_definitions(omptarget.rtl.${machine} PRIVATE
+  target_compile_definitions(omptarget.rtl.host PRIVATE TARGET_ELF_ID=EM_S390)
+  target_compile_definitions(omptarget.rtl.host PRIVATE
       LIBOMPTARGET_NEXTGEN_GENERIC_PLUGIN_TRIPLE="s390x-ibm-linux-gnu")
   list(APPEND LIBOMPTARGET_SYSTEM_TARGETS 
        "s390x-ibm-linux-gnu" "s390x-ibm-linux-gnu-LTO")
diff --git a/offload/src/CMakeLists.txt b/offload/src/CMakeLists.txt
index fb1ad3d7ae7098..8b7be98771a9ed 100644
--- a/offload/src/CMakeLists.txt
+++ b/offload/src/CMakeLists.txt
@@ -74,12 +74,9 @@ endmacro()
 set(LIBOMPTARGET_PLUGINS_TO_LOAD "" CACHE STRING
   "Comma separated list of plugin names to look for at runtime")
 if (NOT LIBOMPTARGET_PLUGINS_TO_LOAD)
-	check_plugin_target(ppc64)
-	check_plugin_target(x86_64)
 	check_plugin_target(cuda)
-	check_plugin_target(aarch64)
 	check_plugin_target(amdgpu)
-	check_plugin_target(s390x)
+	check_plugin_target(host)
 endif()
 
 list(TRANSFORM LIBOMPTARGET_PLUGINS_TO_LOAD PREPEND "\"libomptarget.rtl.")

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on llvm#86868

Summary: Previously we would build all of the plugins by default and then only load some using the `LIBOMPTARGET_PLUGINS_TO_LOAD` variable. This patch renamed this to `LIBOMPTARGET_PLUGINS_TO_BUILD` and changes whether or not it will include the plugin in CMake. Additionally this patch creates a new `Targets.def` file that allows us to enumerate all of the enabled plugins. This is somewhat different from the old method, and it's done this way for future use that will need to be shared. This follows the same method that LLVM uses for its targets, however it does require adding an extra include path. Depends on #86868

Summary: This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on llvm#86971 llvm#86875 llvm#86868

This patch overhauls the `libomptarget` and plugin interface. Currently, we define a C API and compile each plugin as a separate shared library. Then, `libomptarget` loads these API functions and forwards its internal calls to them. This was originally designed to allow multiple implementations of a library to be live. However, since then no one has used this functionality and it prevents us from using much nicer interfaces. If the old behavior is desired it should instead be implemented as a separate plugin. This patch replaces the `PluginAdaptorTy` interface with the `GenericPluginTy` that is used by the plugins. Each plugin exports a `createPlugin_<name>` function that is used to get the specific implementation. This code is now shared with `libomptarget`. There are some notable improvements to this. 1. Massively improved lifetimes of life runtime objects 2. The plugins can use a C++ interface 3. Global state does not need to be duplicated for each plugin + libomptarget 4. Easier to use and add features and improve error handling 5. Less function call overhead / Improved LTO performance. Additional changes in this plugin are related to contending with the fact that state is now shared. Initialization and deinitialization is now handled correctly and in phase with the underlying runtime, allowing us to actually know when something is getting deallocated. Depends on #86971 #86875 #86868

jhuber6 requested review from carlobertolli, dhruvachak, estewart08, jdoerfert, JonChesterfield, ronlieb, saiislam and shiltian March 27, 2024 20:36

llvmbot added the openmp:libomptarget OpenMP offload runtime label Mar 27, 2024

jhuber6 mentioned this pull request Mar 27, 2024

[Libomptarget] Rework interface for enabling plugins #86875

Merged

jhuber6 mentioned this pull request Mar 28, 2024

[Libomptarget] Statically link all plugin runtimes #87009

Merged

shiltian reviewed Mar 29, 2024

View reviewed changes

jplehr approved these changes Apr 10, 2024

View reviewed changes

jhuber6 force-pushed the Rename branch from f8fb701 to 1be9c20 Compare April 26, 2024 18:32

llvmbot added the offload label Apr 26, 2024

jhuber6 merged commit 72b0c11 into llvm:main Apr 26, 2024
5 checks passed

This was referenced Apr 29, 2024

main #90439

Closed

[AArch64] Add support for Cortex-R82AE and improve Cortex-R82 #90440

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Libomptarget] Rename `libomptarget.rtl.x86_64` to `libomptarget.rtl.host` #86868

[Libomptarget] Rename `libomptarget.rtl.x86_64` to `libomptarget.rtl.host` #86868

Uh oh!

jhuber6 commented Mar 27, 2024

Uh oh!

shiltian Mar 29, 2024

Uh oh!

jhuber6 Mar 29, 2024

Uh oh!

shiltian Mar 29, 2024

Uh oh!

jhuber6 Mar 29, 2024

Uh oh!

jplehr Apr 10, 2024

Uh oh!

jplehr left a comment

Uh oh!

jplehr Apr 10, 2024

Uh oh!

llvmbot commented Apr 26, 2024

Uh oh!

Uh oh!

Uh oh!

[Libomptarget] Rename libomptarget.rtl.x86_64 to libomptarget.rtl.host #86868

[Libomptarget] Rename libomptarget.rtl.x86_64 to libomptarget.rtl.host #86868

Uh oh!

Conversation

jhuber6 commented Mar 27, 2024

Uh oh!

shiltian Mar 29, 2024

Choose a reason for hiding this comment

Uh oh!

jhuber6 Mar 29, 2024

Choose a reason for hiding this comment

Uh oh!

shiltian Mar 29, 2024

Choose a reason for hiding this comment

Uh oh!

jhuber6 Mar 29, 2024

Choose a reason for hiding this comment

Uh oh!

jplehr Apr 10, 2024

Choose a reason for hiding this comment

Uh oh!

jplehr left a comment

Choose a reason for hiding this comment

Uh oh!

jplehr Apr 10, 2024

Choose a reason for hiding this comment

Uh oh!

llvmbot commented Apr 26, 2024

Uh oh!

Uh oh!

Uh oh!

[Libomptarget] Rename `libomptarget.rtl.x86_64` to `libomptarget.rtl.host` #86868

[Libomptarget] Rename `libomptarget.rtl.x86_64` to `libomptarget.rtl.host` #86868