Fix interaction of static plugins with -DLLVM_LINK_LLVM_DYLIB=ON.

[efriedma]

Summary

We should link static plugins into libLLVM.so; they shouldn't depend on libLLVM.so.

I'm not completely sure my CMake manipulation is right, but it seems to work.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45571

[serge-sans-paille]

llvm/cmake/modules/AddLLVM.cmake

886

Conceptually, do we want Extensions to be considered as component?

[sylvestre.ledru]

The cmake configure is fixed, thanks.
Running a full build now

[efriedma]

llvm/cmake/modules/AddLLVM.cmake

886

An alternative way to state this question is, should LLVMLTO depend on statically linked plugins directly?

One way of thinking about it is that static plugins are a way to write LLVM components outside the llvm/ tree. Therefore, we statically link them into LTO, and use them automatically.

Alternatively, we could say that plugins are part of the calling tool. In that case, we'd need to remove most of the changes from the LTO library, add some sort of callback, and stick the code to call into the plugins into each tool that calls LTO instead.

Either way works; the end result isn't hugely different. But I think I'd prefer the approach that doesn't involve copy-pasting the plugin registration code into every tool that runs LTO.

[serge-sans-paille]

llvm/cmake/modules/AddLLVM.cmake

886

One way of thinking about it is that static plugins are a way to write LLVM components outside the llvm/ tree.

I like that perspective, it makes sense both conceptually and programmatically. LGTM

polly/lib/CMakeLists.txt

110

I'm currently working on a way to avoid the need of stating that in every plugin, this is super error-prone. It will be based on your patch.

llvm/cmake/modules/AddLLVM.cmake

if (ARG_SUBPROJECT AND LLVM_TOOL_${name_upper}_BUILD)
     set(link_into_tools_default ON)
   endif()
   option(LLVM_${name_upper}_LINK_INTO_TOOLS "Statically link ${name} into tools (if available)" ${link_into_tools_default})
 
   if(LLVM_${name_upper}_LINK_INTO_TOOLS)
     list(REMOVE_ITEM ARG_UNPARSED_ARGUMENTS BUILDTREE_ONLY)
     # process_llvm_pass_plugins takes care of the actual linking, just create an
     # object library as of now
-    add_llvm_library(${name} OBJECT ${ARG_UNPARSED_ARGUMENTS})
+    add_llvm_component_library(${name} OBJECT ${ARG_UNPARSED_ARGUMENTS})
     target_compile_definitions(${name} PRIVATE LLVM_${name_upper}_LINK_INTO_TOOLS)
     set_property(TARGET ${name} APPEND PROPERTY COMPILE_DEFINITIONS LLVM_LINK_INTO_TOOLS)
     if (TARGET intrinsics_gen)
       add_dependencies(obj.${name} intrinsics_gen)
     endif()
     set_property(GLOBAL APPEND PROPERTY LLVM_STATIC_EXTENSIONS ${name})
   elseif(NOT ARG_NO_MODULE)
     add_llvm_library(${name} MODULE ${ARG_UNPARSED_ARGUMENTS})

polly/lib/CMakeLists.txt

 
 # Polly-ACC requires the NVPTX backend to work. Ask LLVM about its libraries.
 set(nvptx_libs)
 if (GPU_CODEGEN)
   # This call emits an error if they NVPTX backend is not enable.
   llvm_map_components_to_libnames(nvptx_libs NVPTX)
 endif ()
 
-if (LLVM_LINK_LLVM_DYLIB)
+if (LLVM_LINK_LLVM_DYLIB AND NOT LLVM_POLLY_LINK_INTO_TOOLS)
   # The shlib/dylib contains all the LLVM components
   # (including NVPTX is enabled) already. Adding them to target_link_libraries
   # would cause them being twice in the address space
   # (their LLVM*.a/so and their copies in libLLVM.so)
   # which results in errors when the two instances try to register the same
   # command-line switches.
   target_link_libraries(Polly PUBLIC LLVM)
 else ()