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
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
