[PATCH] D9509: [cuda] Driver changes to build and stitch together host and device-side CUDA code.

Artem Belevich tra at google.com
Tue Jul 7 13:27:14 PDT 2015


In http://reviews.llvm.org/D9509#200597, @echristo wrote:

> Couple of inline comments, and I'm still not a huge fan of the getTargetToolChain bits. It seems like we should be able to have a single interface to getting a target toolchain that works for both cases. Maybe compute the triple up front for use in the rest of the driver for the host?


Existing code commingles two independent things -- figuring out target triple value and retrieving corresponding ToolChain for a given Triple. My change just refactored out Triple->ToolChain mapping.

> Good lord cuda is terrible. :)


'Quirky' would be a better word, perhaps.


================
Comment at: include/clang/Driver/Driver.h:412-414
@@ -411,2 +411,5 @@
   /// on-demand.
+  const ToolChain &getTargetToolChain(const llvm::opt::ArgList &Args,
+                                      const llvm::Triple &Target) const;
+
   const ToolChain &getToolChain(const llvm::opt::ArgList &Args,
----------------
echristo wrote:
> The comments no longer match the code here.
I believe it still does. My change just split StringRef -> Triple -> Toolchain conversion into StringRaf->Triple and Tuple->ToolChain without change in functionality.



================
Comment at: lib/Driver/Driver.cpp:822-823
@@ -820,3 +821,4 @@
 
 static unsigned PrintActions1(const Compilation &C, Action *A,
-                              std::map<Action*, unsigned> &Ids) {
+                              std::map<Action *, unsigned> &Ids);
+
----------------
echristo wrote:
> Can you rearrange the code so that it doesn't need the forward declaration?
Nope. PrintActions1 and PrintActionList call each other recursively. At least one of them must have forward declaration.


http://reviews.llvm.org/D9509







More information about the cfe-commits mailing list