[all-commits] [llvm/llvm-project] fa4780: [OpenMP][USM] Introduces -fopenmp-force-usm flag (...

Jan Patrick Lehr via All-commits all-commits at lists.llvm.org
Mon Jan 22 12:59:38 PST 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fa4780fa6cc36188b84b2a977ac15351c39d45dd
      https://github.com/llvm/llvm-project/commit/fa4780fa6cc36188b84b2a977ac15351c39d45dd
  Author: Jan Patrick Lehr <jplehr at users.noreply.github.com>
  Date:   2024-01-22 (Mon, 22 Jan 2024)

  Changed paths:
    M clang/include/clang/Basic/LangOptions.def
    M clang/include/clang/Driver/Options.td
    M clang/lib/CodeGen/CGOpenMPRuntime.cpp
    M clang/lib/Driver/ToolChains/Clang.cpp
    A clang/test/OpenMP/force-usm.c
    M openmp/libomptarget/test/lit.cfg
    A openmp/libomptarget/test/offloading/force-usm.cpp

  Log Message:
  -----------
  [OpenMP][USM] Introduces -fopenmp-force-usm flag (#76571)

This flag forces the compiler to generate code for OpenMP target regions
as if the user specified the #pragma omp requires unified_shared_memory
in each source file.

The option does not have a -fno-* friend since OpenMP requires the
unified_shared_memory clause to be present in all source files. Since
this flag does no harm if the clause is present, it can be used in
conjunction. My understanding is that USM should not be turned off
selectively, hence, no -fno- version.

This adds a basic test to check the correct generation of double
indirect access to declare target globals in USM mode vs non-USM mode.
Which I think is the only difference observable in code generation.

This runtime test checks for the (non-)occurence of data movement between host
and device. It does one run without the flag and one with the flag to
also see that both versions behave as expected. In the case w/o the new
flag data movement between host and device is expected. In the case with
the flag such data movement should not be present / reported.




More information about the All-commits mailing list