Skip to content
  1. Apr 07, 2022
    • Michael Kruse's avatar
      [libomptarget] Add device RTL to regression test dependencies. · 7fa7b0cb
      Michael Kruse authored
      In a clean build directory, `check-openmp` or `check-libomptarget` will fail because of missing device RTL .bc files. Ensure that the new targets new custom targets `omptarget.devicertl.nvptx` and `omptarget.devicertl.amdgpu` (corresponding to the plugin rtl targets `omptarget.rtl.cuda`, respectively `omptarget.rlt.amdgpu` ) are dependencies of the regression tests.
      
      Reviewed By: JonChesterfield
      
      Differential Revision: https://reviews.llvm.org/D123177
      7fa7b0cb
  2. Mar 06, 2022
  3. Feb 08, 2022
  4. Feb 04, 2022
    • Joseph Huber's avatar
      [OpenMP] Completely remove old device runtime · 034adaf5
      Joseph Huber authored
      This patch completely removes the old OpenMP device runtime. Previously,
      the old runtime had the prefix `libomptarget-new-` and the old runtime
      was simply called `libomptarget-`. This patch makes the formerly new
      runtime the only runtime available. The entire project has been deleted,
      and all references to the `libomptarget-new` runtime has been replaced
      with `libomptarget-`.
      
      Reviewed By: JonChesterfield
      
      Differential Revision: https://reviews.llvm.org/D118934
      034adaf5
  5. Feb 01, 2022
  6. Jan 19, 2022
  7. Dec 07, 2021
  8. Dec 06, 2021
  9. Nov 29, 2021
    • Matt Arsenault's avatar
      OpenMP: Correctly query location for amdgpu-arch · 935abeaa
      Matt Arsenault authored
      This was trying to figure out the build path for amdgpu-arch, and
      making assumptions about where it is which were not working on my
      system. Whether a standalone build or not, we should have a proper
      imported target to get the location from.
      935abeaa
  10. Oct 28, 2021
  11. Oct 23, 2021
  12. Sep 02, 2021
    • Jon Chesterfield's avatar
      [libomptarget][amdgpu] Drop env variables · 3153bdd5
      Jon Chesterfield authored
      Use the same debug print as the rest of libomptarget plugins with
      the same environment control. Also drop the max queue size debugging hook as
      I don't believe it is still in use, can bring it back near the rest of the env
      handling in rtl.cpp if someone objects.
      
      That makes most of rt.h and all of utils.cpp unused. Clean that up and simplify
      control flow in a couple of places.
      
      Behaviour change is that debug prints that used to use the old environment
      variable now use the new one and print in slightly different format, and the
      removal of the max queue size variable.
      
      Reviewed By: pdhaliwal
      
      Differential Revision: https://reviews.llvm.org/D108784
      3153bdd5
  13. Sep 01, 2021
  14. Aug 26, 2021
  15. Aug 24, 2021
  16. Aug 08, 2021
  17. Jul 26, 2021
  18. Jul 25, 2021
  19. Jul 22, 2021
    • Jon Chesterfield's avatar
      [libomptarget][amdgpu] Implement dlopen of libhsa · 1a965706
      Jon Chesterfield authored
      AMDGPU plugin equivalent of D95155, build without HSA installed locally
      
      Compiles a new file, plugins/amdgpu/dynamic_hsa/hsa.cpp, to an object file that
      exposes the same symbols that the plugin presently uses from hsa. The object
      file contains dlopen of hsa and cached dlsym calls. Also provides header files
      corresponding to the subset that is used.
      
      This is behind a feature flag, LIBOMPTARGET_FORCE_DLOPEN_LIBHSA, default off.
      That allows developers to build against the dlopen/dlsym implementation, e.g.
      while testing this mode.
      
      Enabling by default will cause this plugin to build on a wider variety of
      machines than it does at present so may break some CI builds. That risk can
      be minimised by reviewing the header dependencies of the library and ensuring
      it doesn't use any libraries that are not already used by libomptarget.
      
      Separating the implementation from enabling by default in case the latter needs
      to be rolled back after wider CI results.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D106559
      1a965706
  20. Jun 16, 2021
  21. May 10, 2021
  22. Jan 12, 2021
    • Shilei Tian's avatar
      [OpenMP] Fixed include directories for OpenMP when building OpenMP with LLVM_ENABLE_RUNTIMES · bdd1ad5e
      Shilei Tian authored
      Some LLVM headers are generated by CMake. Before the installation,
      LLVM's headers are distributed everywhere, some of which are in
      `${LLVM_SRC_ROOT}/llvm/include/llvm`, and some are in
      `${LLVM_BINARY_ROOT}/include/llvm`. After intallation, they're all in
      `${LLVM_INSTALLATION_ROOT}/include/llvm`.
      
      OpenMP now depends on LLVM headers. Some headers depend on headers generated
      by CMake. When building OpenMP along with LLVM, a.k.a via `LLVM_ENABLE_RUNTIMES`,
      we need to tell OpenMP where it can find those headers, especially those still
      have not been copied/installed.
      
      Reviewed By: jdoerfert, jhuber6
      
      Differential Revision: https://reviews.llvm.org/D94534
      bdd1ad5e
  23. Jan 11, 2021
    • Shilei Tian's avatar
      [OpenMP] Take elf_common.c as a interface library · a81c68ae
      Shilei Tian authored
      For now `elf_common.c` is taken as a common part included into
      different plugin implementations directly via
      `#include "../../common/elf_common.c"`, which is not a best practice. Since it
      is simple enough such that we don't need to create a real library for it, we just
      take it as a interface library so that other targets can link it directly. Another
      advantage of this method is, we don't need to add the folder into header search
      path which can potentially pollute the search path.
      
      VE and AMD platforms have not been tested because I don't have target machines.
      
      Reviewed By: JonChesterfield
      
      Differential Revision: https://reviews.llvm.org/D94443
      a81c68ae
  24. Dec 09, 2020
  25. Oct 21, 2020
    • Jon Chesterfield's avatar
      [libomptarget] Require LLVM source tree to build libomptarget · 26790ed2
      Jon Chesterfield authored
      [libomptarget] Require LLVM source tree to build libomptarget
      
      This is to permit reliably #including files from the LLVM tree in libomptarget,
      as an improvement on the copy and paste that is currently in use. See D87841
      for the first example of removing duplication given this new requirement.
      
      The weekly openmp dev call reached consensus on this approach. See also D87841
      for some alternatives that were considered. In the future, we may want to
      introduce a new top level repo for shared constants, or start using the ADT
      library within openmp.
      
      This will break sufficiently exotic build systems, trivial fixes as below.
      
      Building libomptarget as part of the monorepo will continue to work.
      If openmp is built separately, it now requires a cmake macro indicating
      where to find the LLVM source tree.
      
      If openmp is built separately, without the llvm source tree already on disk,
      the build machine will need a copy of a subset of the llvm source tree and
      the cmake macro indicating where it is.
      
      Reviewed By: protze.joachim
      
      Differential Revision: https://reviews.llvm.org/D89426
      26790ed2
  26. Oct 15, 2020
    • JonChesterfield's avatar
      [openmp][libomptarget] Include header from LLVM source tree · 7d2ecef5
      JonChesterfield authored
      [openmp][libomptarget] Include header from LLVM source tree
      
      The change is to the amdgpu plugin so is unlikely to break anything.
      
      The point of contention is whether libomptarget can depend on LLVM.
      A community discussion was cautiously not opposed yesterday.
      
      This introduces a compile time dependency on the LLVM source tree, in this case
      expressed as skipping the building of the plugin if LLVM_MAIN_INCLUDE_DIR is not
      set. One the source files will #include llvm/Frontend/OpenMP/OMPGridValues.h,
      instead of copy&pasting the numbers across.
      
      For users that download the monorepo, the llvm tree is already on disk. This will
      inconvenience users who download only the openmp source as a tar, as they would
      now also have to download (at least a file or two) from the llvm source, if they want
      to build the parts of the openmp project that (post this patch) depend on llvm.
      
      There was interest expressed in going further - using llvm tools as part of
      building libomp, or linking against llvm libraries. That seems less clear cut
      an improvement and worthy of further discussion. This patch seeks only to change
      policy to support openmp depending on the llvm source tree. Including in the
      other direction, or using libraries / tools etc, are purposefully out of scope.
      
      Reviewers are a best guess at interested parties, please feel free to add others
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D87841
      7d2ecef5
  27. Aug 26, 2020
  28. Aug 19, 2020
  29. Aug 16, 2020
    • Jon Chesterfield's avatar
      [libomptarget] Implement host plugin for amdgpu · d0b31295
      Jon Chesterfield authored
      [libomptarget] Implement host plugin for amdgpu
      
      Replacement for D71384. Primary difference is inlining the dependency on atmi
      followed by extensive simplification and bugfixes. This is the latest version
      from https://github.com/ROCm-Developer-Tools/amd-llvm-project/tree/aomp12 with
      minor patches and a rename from hsa to amdgpu, on the basis that this can't be
      used by other implementations of hsa without additional work.
      
      This will not build unless the ROCM_DIR variable is passed so won't break other
      builds. That variable is used to locate two amdgpu specific libraries that ship
      as part of rocm:
      libhsakmt at https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface
      libhsa-runtime64 at https://github.com/RadeonOpenCompute/ROCR-Runtime
      These libraries build from source. The build scripts in those repos are for
      shared libraries, but can be adapted to statically link both into this plugin.
      
      There are caveats.
      - This works well enough to run various tests and benchmarks, and will be used
        to support the current clang bring up
      - It is adequately thread safe for the above but there will be races remaining
      - It is not stylistically correct for llvm, though has had clang-format run
      - It has suboptimal memory management and locking strategies
      - The debug printing / error handling is inconsistent
      
      I would like to contribute this pretty much as-is and then improve it in-tree.
      This would be advantagous because the aomp12 branch that was in use for fixing
      this codebase has just been joined with the amd internal rocm dev process.
      
      Reviewed By: jdoerfert
      
      Differential Revision: https://reviews.llvm.org/D85742
      d0b31295
Loading