[PATCH] D13144: [CUDA] propagate to CUDA sub-compilations target triple of opposite side.

Artem Belevich via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 28 16:05:52 PDT 2015

tra added inline comments.

Comment at: lib/Driver/Driver.cpp:503
@@ -502,3 +502,3 @@
   if (TC.getTriple().isOSBinFormatMachO())
-    BuildUniversalActions(C->getDefaultToolChain(), C->getArgs(), Inputs,
+    BuildUniversalActions(*C, C->getDefaultToolChain(), C->getArgs(), Inputs,
echristo wrote:
> Can pass one or the other here? I don't think you need both a reference to C and one of its members?
I can fold getArgs and getActions for BuildUniversalActions(), but not toolchain as it's called with different ones.

Comment at: lib/Driver/Driver.cpp:1285-1291
@@ -1284,6 +1284,9 @@
+                 std::unique_ptr<Action> HostAction, ActionList &Actions) {
   // Figure out which NVPTX triple to use for device-side compilation based on
   // whether host is 64-bit.
   const char *DeviceTriple = TC.getTriple().isArch64Bit()
                                  ? "nvptx64-nvidia-cuda"
                                  : "nvptx-nvidia-cuda";
+  C.setCudaDeviceToolChain(
+      &D.getToolChain(C.getArgs(), llvm::Triple(DeviceTriple)));
   Arg *PartialCompilationArg = Args.getLastArg(options::OPT_cuda_host_only,
echristo wrote:
> Can't you now do all of this in BuildCompilation?
I could, but i'd prefer to avoid putting hardcoded cuda logic into otherwise generic BuildCompilation for no good reason.

Here is where we start creating device-side actions and have all relevant info for that so it appears to be a sensible place to pick an appropriate toolchain for that as well.

When we have better support for multiple compilation targets toolchain selection would probably be more generic and would migrate towards BuildCompilation, but we're not there yet. :-)


More information about the cfe-commits mailing list