[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreFirst of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOSbuilds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as`CMAKE_INSTALL_BI
[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymoreFirst of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOSbuilds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then whendownstream projects try to install there too this breaks because ourbuilds always install to fresh directories for isolation's sake.Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against theother specially crafted `LLVM_CONFIG_*` variables substituted in`llvm/cmake/modules/LLVMConfig.cmake.in`.@beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix adangling reference in `AddLLVM`, but I am suspicious of how thisvariable doesn't follow the pattern.Those other ones are carefully made to be build-time vs install-timevariables depending on which `LLVMConfig.cmake` is being generated, arecarefully made relative as appropriate, etc. etc. For my NixOS use-casethey are also fine because they are never used as downstream installvariables, only for reading not writing.To avoid the problems I face, and restore symmetry, I deleted theexported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.`AddLLVM` now instead expects each project to define its own, and theydo so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined inthe usual way, matching the other remaining exported variables.For the `AddLLVM` changes, I tried to copy the existing pattern ofinternal vs non-internal or for LLVM vs for downstream function/macronames, but it would good to confirm I did that correctly.Reviewed By: nikicDifferential Revision: https://reviews.llvm.org/D117977
show more ...
Revert "[cmake] Don't export `LLVM_TOOLS_INSTALL_DIR` anymore"This reverts commit d5daa5c5b091cafb9b7ffd19b5dfa2daadef3229.
[Libomptarget] Remove global include directory from libomptargetWe used to globally include the libomptarget include directory for allprojects. This caused some conflicts with the other files name
[Libomptarget] Remove global include directory from libomptargetWe used to globally include the libomptarget include directory for allprojects. This caused some conflicts with the other files named"Debug.h". This patch changes the cmake to include these files via thetarget include instead.Reviewed By: tianshilei1992Differential Revision: https://reviews.llvm.org/D125563
[OpenMP] Fix linker error when building info toolSummary:The changes made in D123177 added new targets to the`LIBOMPTARGET_TESTED_PLUGINS` variable which was linked against whenbuilding the `llv
[OpenMP] Fix linker error when building info toolSummary:The changes made in D123177 added new targets to the`LIBOMPTARGET_TESTED_PLUGINS` variable which was linked against whenbuilding the `llvm-omp-target-info` tool. This caused linker errors onthe export scripts. This patch removes that dependency, it still buildsand runs as expected so I will assume it's correct.
[OpenMP] Fixing llvm-omp-device-info compilation with runtimesWhen using `-DLLVM_ENABLED_RUNTIMES` instead of `-DLLVM_ENABLED_PROJECTS`the `llvm-omp-device-info` tool is not compiled or installed.
[OpenMP] Fixing llvm-omp-device-info compilation with runtimesWhen using `-DLLVM_ENABLED_RUNTIMES` instead of `-DLLVM_ENABLED_PROJECTS`the `llvm-omp-device-info` tool is not compiled or installed.In general, no llvm tool would be build on runtimes, because the-DLLVM_BUILD_TOOLS flag is removed by the way runtimes compilation callscmake again.This patch is simple. Just forward the value of this flag to theruntime cmake command.I'm also removing an unnecessary comment in the compilation of the toolDifferential Revision: https://reviews.llvm.org/D107177
[OpenMP][Tool] Introducing the `llvm-omp-device-info` toolThis patch introduces the `llvm-omp-device-info` tool, which uses theomptarget library and interface to query the device info from all the
[OpenMP][Tool] Introducing the `llvm-omp-device-info` toolThis patch introduces the `llvm-omp-device-info` tool, which uses theomptarget library and interface to query the device info from all theavailable devices as seen by OpenMP. This is inspired by PGI's `pgaccelinfo`Since omptarget usually requires a description structure with executablekernels, I split the initialization of the RTLs and Devices to be able toinitialize all possible devices and query each of them.This revision relies on the patch that introduces the print device info.A limitation is that the order in which the devices are initialized, and thecorresponding device ID is not necesarily the one seen by OpenMP.The changes are as follows:1. Separate the RTL initialization that was performed in `RegisterLib` to its own `initRTLonce` function2. Create an `initAllRTLs` method that initializes all available RTLs at runtime3. Created the `llvm-deviceinfo.cpp` tool that uses `omptarget` to query each device and prints its information.Example Output:```Device (0): print_device_info not implementedDevice (1): print_device_info not implementedDevice (2): print_device_info not implementedDevice (3): print_device_info not implementedDevice (4): CUDA Driver Version: 11000 CUDA Device Number: 0 Device Name: Quadro P1000 Global Memory Size: 4236312576 bytes Number of Multiprocessors: 5 Concurrent Copy and Execution: Yes Total Constant Memory: 65536 bytes Max Shared Memory per Block: 49152 bytes Registers per Block: 65536 Warp Size: 32 Threads Maximum Threads per Block: 1024 Maximum Block Dimensions: 1024, 1024, 64 Maximum Grid Dimensions: 2147483647 x 65535 x 65535 Maximum Memory Pitch: 2147483647 bytes Texture Alignment: 512 bytes Clock Rate: 1480500 kHz Execution Timeout: Yes Integrated Device: No Can Map Host Memory: Yes Compute Mode: DEFAULT Concurrent Kernels: Yes ECC Enabled: No Memory Clock Rate: 2505000 kHz Memory Bus Width: 128 bits L2 Cache Size: 1048576 bytes Max Threads Per SMP: 2048 Async Engines: Yes (2) Unified Addressing: Yes Managed Memory: Yes Concurrent Managed Memory: Yes Preemption Supported: Yes Cooperative Launch: Yes Multi-Device Boars: No Compute Capabilities: 61```Reviewed By: tianshilei1992Differential Revision: https://reviews.llvm.org/D106752