[PATCH] D34784: [OpenMP] Add flag for specifying the target device architecture for OpenMP device offloading

Hal Finkel via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 30 17:51:23 PDT 2017


hfinkel added inline comments.


================
Comment at: include/clang/Driver/Options.td:453
+def Xopenmp_target : Separate<["-"], "Xopenmp-target">,
+  HelpText<"Pass arguments to target offloading toolchain.">;
+def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
----------------
Can this be?

    HelpText<"Pass <arg> to the target offloading toolchain.">,
    MetaVarName<"<arg>">;


================
Comment at: include/clang/Driver/Options.td:455
+def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
+  HelpText<"Pass arguments to target offloading toolchain. First entry is a triple that identifies the toolchain.">;
 def z : Separate<["-"], "z">, Flags<[LinkerInput, RenderAsInput]>,
----------------
  HelpText<"Pass <arg> to the specified target offloading toolchain. The triple that identifies the toolchain must be provided after the equals sign.">, MetaVarName<"<arg>">;


================
Comment at: lib/Driver/ToolChains/Cuda.cpp:443
+
+    // Get the compute capability from the -fopenmp-targets flag.
+    // The default compute capability is sm_20 since this is a CUDA
----------------
Is this first sentence accurate?


================
Comment at: lib/Driver/ToolChains/Cuda.cpp:444
+    // Get the compute capability from the -fopenmp-targets flag.
+    // The default compute capability is sm_20 since this is a CUDA
+    // tool chain.
----------------
This comment should be moved down to where the sm_20 default is added.


================
Comment at: lib/Driver/ToolChains/Cuda.cpp:446
+    // tool chain.
+    auto OptList = Args.getAllArgValues(options::OPT_Xopenmp_target_EQ);
+
----------------
Why is this logic in this function? Don't you need the same logic in Generic_GCC::TranslateArgs to handle non-CUDA offloading toolchains?



================
Comment at: lib/Driver/ToolChains/Cuda.cpp:469
+    // toolchain specified).
+    assert(Args.getAllArgValues(options::OPT_fopenmp_targets_EQ).size() == 1 &&
+        "Target toolchain not specified on -Xopenmp-target and cannot be deduced.");
----------------
A user can trigger this assert, right? Please make this a diagnostic error instead.


================
Comment at: lib/Driver/ToolChains/Cuda.cpp:474
+    for (StringRef Opt : OptList) {
+      AddMArchOption(DAL, Opts, Opt);
+    }
----------------
Shouldn't you be adding all of the options, not just the -march= ones?


================
Comment at: lib/Driver/ToolChains/Cuda.cpp:478
+    auto MArchList = DAL->getAllArgValues(options::OPT_march_EQ);
+    assert(MArchList.size() < 2 && "At most one GPU arch allowed.");
+    if (MArchList.empty())
----------------
Can a user hit this? If so, it must be an actual diagnostic.


================
Comment at: test/Driver/openmp-offload.c:607
+
+// CHK-FOPENMP-EQ-TARGET: clang{{.*}} argument unused during compilation: '-Xopenmp-target=powerpc64le-ibm-linux-gnu -march=pwr8'
+
----------------
I don't see why you'd check that the arguments are unused. They should be used. One exception might be that you might want to force -Xopenmp-target=foo to be unused if foo is not a currently-targeted offloading triple. There could be a separate test case for that.

Otherwise, I think you should be able to check the relevant backend commands, no? (something like where CHK-COMMANDS is used above in this file).


https://reviews.llvm.org/D34784





More information about the cfe-commits mailing list