Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL275895: [Driver] Compute effective target triples once per 
job (NFCI) (authored by vedantk).

Changed prior to commit:
  https://reviews.llvm.org/D22290?vs=64023=64367#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D22290

Files:
  cfe/trunk/docs/ReleaseNotes.rst
  cfe/trunk/include/clang/Driver/SanitizerArgs.h
  cfe/trunk/include/clang/Driver/Tool.h
  cfe/trunk/include/clang/Driver/ToolChain.h
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/lib/Driver/ToolChains.cpp
  cfe/trunk/lib/Driver/ToolChains.h
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Driver/Tools.h

Index: cfe/trunk/docs/ReleaseNotes.rst
===
--- cfe/trunk/docs/ReleaseNotes.rst
+++ cfe/trunk/docs/ReleaseNotes.rst
@@ -121,7 +121,8 @@
 Clang. If upgrading an external codebase that uses Clang as a library,
 this section should help get you past the largest hurdles of upgrading.
 
--  ...
+- Classes which inherit from ``driver::Tool`` must be updated to use effective
+  target triples when constructing jobs.
 
 AST Matchers
 
Index: cfe/trunk/include/clang/Driver/SanitizerArgs.h
===
--- cfe/trunk/include/clang/Driver/SanitizerArgs.h
+++ cfe/trunk/include/clang/Driver/SanitizerArgs.h
@@ -16,6 +16,10 @@
 #include 
 #include 
 
+namespace llvm {
+class Triple;
+}
+
 namespace clang {
 namespace driver {
 
@@ -66,7 +70,8 @@
   bool requiresPIE() const;
   bool needsUnwindTables() const;
   bool linkCXXRuntimes() const { return LinkCXXRuntimes; }
-  void addArgs(const ToolChain , const llvm::opt::ArgList ,
+  void addArgs(const ToolChain , const llvm::Triple ,
+   const llvm::opt::ArgList ,
llvm::opt::ArgStringList , types::ID InputType) const;
 };
 
Index: cfe/trunk/include/clang/Driver/ToolChain.h
===
--- cfe/trunk/include/clang/Driver/ToolChain.h
+++ cfe/trunk/include/clang/Driver/ToolChain.h
@@ -260,11 +260,13 @@
 return ToolChain::CST_Libstdcxx;
   }
 
-  virtual std::string getCompilerRT(const llvm::opt::ArgList ,
+  virtual std::string getCompilerRT(const llvm::Triple ,
+const llvm::opt::ArgList ,
 StringRef Component,
 bool Shared = false) const;
 
-  const char *getCompilerRTArgString(const llvm::opt::ArgList ,
+  const char *getCompilerRTArgString(const llvm::Triple ,
+ const llvm::opt::ArgList ,
  StringRef Component,
  bool Shared = false) const;
   /// needsProfileRT - returns true if instrumentation profile is on.
@@ -410,7 +412,8 @@
   const llvm::opt::ArgList , llvm::opt::ArgStringList ) const;
   /// addProfileRTLibs - When -fprofile-instr-profile is specified, try to pass
   /// a suitable profile runtime library to the linker.
-  virtual void addProfileRTLibs(const llvm::opt::ArgList ,
+  virtual void addProfileRTLibs(const llvm::Triple ,
+const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const;
 
   /// \brief Add arguments to use system-specific CUDA includes.
Index: cfe/trunk/include/clang/Driver/Tool.h
===
--- cfe/trunk/include/clang/Driver/Tool.h
+++ cfe/trunk/include/clang/Driver/Tool.h
@@ -14,6 +14,7 @@
 #include "llvm/Support/Program.h"
 
 namespace llvm {
+class Triple;
 namespace opt {
   class ArgList;
 }
@@ -127,6 +128,7 @@
   virtual void ConstructJob(Compilation , const JobAction ,
 const InputInfo ,
 const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const = 0;
 };
Index: cfe/trunk/lib/Driver/SanitizerArgs.cpp
===
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp
@@ -602,7 +602,9 @@
   CmdArgs.push_back(Args.MakeArgString(LinkerOptionFlag));
 }
 
-void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList ,
+void SanitizerArgs::addArgs(const ToolChain ,
+const llvm::Triple ,
+const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.
@@ -626,21 +628,24 @@
 // Instruct the code generator to embed linker directives in the object file
 // that cause the 

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

vsk updated this revision to Diff 64023.
vsk added a comment.

- Addressed Paul's comment: added a release note about this.
- Rebased onto master to pick up an Xray change.


https://reviews.llvm.org/D22290

Files:
  docs/ReleaseNotes.rst
  include/clang/Driver/Driver.h
  include/clang/Driver/SanitizerArgs.h
  include/clang/Driver/Tool.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Driver.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h

Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -60,7 +60,8 @@
const InputInfoList ,
const ToolChain *AuxToolChain) const;
 
-  void AddAArch64TargetArgs(const llvm::opt::ArgList ,
+  void AddAArch64TargetArgs(const llvm::Triple ,
+const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const;
   void AddARMTargetArgs(const llvm::Triple ,
 const llvm::opt::ArgList ,
@@ -115,6 +116,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -132,6 +134,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -159,6 +162,7 @@
   bool hasIntegratedAssembler() const override { return true; }
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 
@@ -218,6 +222,7 @@
llvm::opt::ArgStringList ) const;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -233,6 +238,7 @@
llvm::opt::ArgStringList ) const;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -247,6 +253,7 @@
   bool hasIntegratedCPP() const override { return false; }
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -262,6 +269,7 @@
   bool hasIntegratedCPP() const override;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -323,6 +331,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -362,6 +371,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -382,6 +392,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -394,6 +405,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -408,6 +420,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -421,6 +434,7 @@

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Paul Robinson via cfe-commits]

probinson added a subscriber: probinson.
probinson added a comment.

On the thread you suggested it would affect out-of-tree targets, so this 
probably deserves a release note?


https://reviews.llvm.org/D22290



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Jul-13, at 11:18, Vedant Kumar  wrote:
> 
>> 
>> On Jul 13, 2016, at 10:30 AM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> 
>>> On 2016-Jul-12, at 18:59, Vedant Kumar  wrote:
>>> 
 
 On Jul 12, 2016, at 6:23 PM, Duncan P. N. Exon Smith 
  wrote:
 
 
> On 2016-Jul-12, at 17:47, Vedant Kumar  wrote:
> 
> 
>> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith 
>>  wrote:
>> 
>> 
>>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>>> 
>>> vsk created this revision.
>>> vsk added a reviewer: dexonsmith.
>>> vsk added a subscriber: cfe-commits.
>>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>>> 
>>> Compute an effective target triple exactly once in ConstructJob(), and
>>> then simply pass around const references to it. This eliminates wasteful
>>> re-computation of effective triples (e.g in getARMFloatABI()).
>>> 
>>> http://reviews.llvm.org/D22290
>>> 
>>> Files:
>>> include/clang/Driver/SanitizerArgs.h
>>> include/clang/Driver/Tool.h
>>> include/clang/Driver/ToolChain.h
>>> lib/Driver/Driver.cpp
>>> lib/Driver/SanitizerArgs.cpp
>>> lib/Driver/ToolChain.cpp
>>> lib/Driver/ToolChains.cpp
>>> lib/Driver/ToolChains.h
>>> lib/Driver/Tools.cpp
>>> lib/Driver/Tools.h
>>> 
>>> 
>> 
>>> Index: lib/Driver/Driver.cpp
>>> ===
>>> --- lib/Driver/Driver.cpp
>>> +++ lib/Driver/Driver.cpp
>>> @@ -2112,7 +2112,21 @@
>>>  AtTopLevel, MultipleArchs),
>>>BaseInput);
>>> 
>>> +  llvm::Triple EffectiveTriple;
>>> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
>>> +  if (InputInfos.size() != 1) {
>>> +EffectiveTriple = llvm::Triple(
>>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>>> +  } else {
>>> +// Pass along the input type if it can be unambiguously determined.
>>> +EffectiveTriple =
>>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>>> +Args, InputInfos[0].getType()));
 
 It looks to me like this could call InputInfos[0].getType() and pass it 
 into ComputeEffectiveClangTriple in cases where previously the type-less 
 overload (which defaults to types::TY_Invalid) would have been called.
>>> 
>>> You're right that this is a behavior change!
>>> 
>>> The site you identified below (in ComputeLLVMTriple()) looks like the only
>>> place where ComputeEffectiveClangTriple's output is affected by InputType.
>>> 
 
 Previously, the type was only specified in ClangAs::ConstructJob.  It only 
 seems to make a difference for this logic in ToolChain::ComputeLLVMTriple:
 
  if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
   options::OPT_mno_thumb, ThumbDefault)) || IsMProfile) {
if (IsBigEndian)
  ArchName = "thumbeb";
else
  ArchName = "thumb";
  }
 
 Is it possible that a single input file will be types::TY_PP_ASM for a 
 caller other than ClangAs?
 - If not, why not?
 - If so, this looks like a behaviour change.  Is that a bugfix, or a new 
 bug?
> 
> SHAVE::Assembler is the only other tool which expects to deal with exactly one
> input with type TY_PP_Asm. However, not all implementations of ConstructJob()
> require or compute effective triples. In this case, the SHAVE assembler 
> doesn't
> use effective triples, so the way we compute them in 
> BuildJobsForActionNoCache()
> can't alter its behavior.
> 
> ISTM that the patch as-written doesn't change the effective triples seen by
> Tools which actually require effective triples. So, I think I spoke too soon
> when I said this is a behavior change!
> 
> To recap: We only pass InputInfos[0].getType() to 
> ComputeEffectiveClangTriple()
> when there's a single InputInfo. This can only break implementations which (1)
> actually use effective triples and (2) have custom triple-creation code which
> *always* expects InputType to be TY_INVALID.
> 
> We don't have any implementations like that in tree.

Okay, this seems like a great cleanup then.  LGTM.

> 
> vedant
> 
>>> 
>>> I'm not sure. I'll try and come up with a test that exposes a behavior 
>>> change.
>> 
>> Okay, great.
>> 
>>> 
 
>>> +  }
>>> +
>>> if (CCCPrintBindings && !CCGenDiagnostics) {
>>> +// FIXME: We should be able to use the effective triple here, but 
>>> doing so
>>> +// breaks some multi-arch tests.
>> 
>> This is interesting.  Why does it break the tests?
> 
> It breaks these two tests:
> 
> test/Driver/darwin-dsymutil.c
> 

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 13, 2016, at 10:30 AM, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2016-Jul-12, at 18:59, Vedant Kumar  wrote:
>> 
>>> 
>>> On Jul 12, 2016, at 6:23 PM, Duncan P. N. Exon Smith  
>>> wrote:
>>> 
>>> 
 On 2016-Jul-12, at 17:47, Vedant Kumar  wrote:
 
 
> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith 
>  wrote:
> 
> 
>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>> 
>> vsk created this revision.
>> vsk added a reviewer: dexonsmith.
>> vsk added a subscriber: cfe-commits.
>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>> 
>> Compute an effective target triple exactly once in ConstructJob(), and
>> then simply pass around const references to it. This eliminates wasteful
>> re-computation of effective triples (e.g in getARMFloatABI()).
>> 
>> http://reviews.llvm.org/D22290
>> 
>> Files:
>> include/clang/Driver/SanitizerArgs.h
>> include/clang/Driver/Tool.h
>> include/clang/Driver/ToolChain.h
>> lib/Driver/Driver.cpp
>> lib/Driver/SanitizerArgs.cpp
>> lib/Driver/ToolChain.cpp
>> lib/Driver/ToolChains.cpp
>> lib/Driver/ToolChains.h
>> lib/Driver/Tools.cpp
>> lib/Driver/Tools.h
>> 
>> 
> 
>> Index: lib/Driver/Driver.cpp
>> ===
>> --- lib/Driver/Driver.cpp
>> +++ lib/Driver/Driver.cpp
>> @@ -2112,7 +2112,21 @@
>>   AtTopLevel, MultipleArchs),
>> BaseInput);
>> 
>> +  llvm::Triple EffectiveTriple;
>> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
>> +  if (InputInfos.size() != 1) {
>> +EffectiveTriple = llvm::Triple(
>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>> +  } else {
>> +// Pass along the input type if it can be unambiguously determined.
>> +EffectiveTriple =
>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>> +Args, InputInfos[0].getType()));
>>> 
>>> It looks to me like this could call InputInfos[0].getType() and pass it 
>>> into ComputeEffectiveClangTriple in cases where previously the type-less 
>>> overload (which defaults to types::TY_Invalid) would have been called.
>> 
>> You're right that this is a behavior change!
>> 
>> The site you identified below (in ComputeLLVMTriple()) looks like the only
>> place where ComputeEffectiveClangTriple's output is affected by InputType.
>> 
>>> 
>>> Previously, the type was only specified in ClangAs::ConstructJob.  It only 
>>> seems to make a difference for this logic in ToolChain::ComputeLLVMTriple:
>>> 
>>>   if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
>>>options::OPT_mno_thumb, ThumbDefault)) || IsMProfile) {
>>> if (IsBigEndian)
>>>   ArchName = "thumbeb";
>>> else
>>>   ArchName = "thumb";
>>>   }
>>> 
>>> Is it possible that a single input file will be types::TY_PP_ASM for a 
>>> caller other than ClangAs?
>>> - If not, why not?
>>> - If so, this looks like a behaviour change.  Is that a bugfix, or a new 
>>> bug?

SHAVE::Assembler is the only other tool which expects to deal with exactly one
input with type TY_PP_Asm. However, not all implementations of ConstructJob()
require or compute effective triples. In this case, the SHAVE assembler doesn't
use effective triples, so the way we compute them in BuildJobsForActionNoCache()
can't alter its behavior.

ISTM that the patch as-written doesn't change the effective triples seen by
Tools which actually require effective triples. So, I think I spoke too soon
when I said this is a behavior change!

To recap: We only pass InputInfos[0].getType() to ComputeEffectiveClangTriple()
when there's a single InputInfo. This can only break implementations which (1)
actually use effective triples and (2) have custom triple-creation code which
*always* expects InputType to be TY_INVALID.

We don't have any implementations like that in tree.

vedant

>> 
>> I'm not sure. I'll try and come up with a test that exposes a behavior 
>> change.
> 
> Okay, great.
> 
>> 
>>> 
>> +  }
>> +
>> if (CCCPrintBindings && !CCGenDiagnostics) {
>> +// FIXME: We should be able to use the effective triple here, but 
>> doing so
>> +// breaks some multi-arch tests.
> 
> This is interesting.  Why does it break the tests?
 
 It breaks these two tests:
 
 test/Driver/darwin-dsymutil.c
 test/Driver/darwin-debug-version.c
 
 The tests expect "-ccc-print-bindings" to spit out a default triple, 
 namely:
 
 x86_64-apple-darwin10
 
 Printing out the effective triple means we get this instead:
 
 x86_64-apple-macosx10.6.0
 
 There's 

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Jul-12, at 18:59, Vedant Kumar  wrote:
> 
>> 
>> On Jul 12, 2016, at 6:23 PM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> 
>>> On 2016-Jul-12, at 17:47, Vedant Kumar  wrote:
>>> 
>>> 
 On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith 
  wrote:
 
 
> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
> 
> vsk created this revision.
> vsk added a reviewer: dexonsmith.
> vsk added a subscriber: cfe-commits.
> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
> 
> Compute an effective target triple exactly once in ConstructJob(), and
> then simply pass around const references to it. This eliminates wasteful
> re-computation of effective triples (e.g in getARMFloatABI()).
> 
> http://reviews.llvm.org/D22290
> 
> Files:
> include/clang/Driver/SanitizerArgs.h
> include/clang/Driver/Tool.h
> include/clang/Driver/ToolChain.h
> lib/Driver/Driver.cpp
> lib/Driver/SanitizerArgs.cpp
> lib/Driver/ToolChain.cpp
> lib/Driver/ToolChains.cpp
> lib/Driver/ToolChains.h
> lib/Driver/Tools.cpp
> lib/Driver/Tools.h
> 
> 
 
> Index: lib/Driver/Driver.cpp
> ===
> --- lib/Driver/Driver.cpp
> +++ lib/Driver/Driver.cpp
> @@ -2112,7 +2112,21 @@
>AtTopLevel, MultipleArchs),
>  BaseInput);
> 
> +  llvm::Triple EffectiveTriple;
> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
> +  if (InputInfos.size() != 1) {
> +EffectiveTriple = llvm::Triple(
> +T->getToolChain().ComputeEffectiveClangTriple(Args));
> +  } else {
> +// Pass along the input type if it can be unambiguously determined.
> +EffectiveTriple =
> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
> +Args, InputInfos[0].getType()));
>> 
>> It looks to me like this could call InputInfos[0].getType() and pass it into 
>> ComputeEffectiveClangTriple in cases where previously the type-less overload 
>> (which defaults to types::TY_Invalid) would have been called.
> 
> You're right that this is a behavior change!
> 
> The site you identified below (in ComputeLLVMTriple()) looks like the only
> place where ComputeEffectiveClangTriple's output is affected by InputType.
> 
>> 
>> Previously, the type was only specified in ClangAs::ConstructJob.  It only 
>> seems to make a difference for this logic in ToolChain::ComputeLLVMTriple:
>> 
>>if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
>> options::OPT_mno_thumb, ThumbDefault)) || IsMProfile) {
>>  if (IsBigEndian)
>>ArchName = "thumbeb";
>>  else
>>ArchName = "thumb";
>>}
>> 
>> Is it possible that a single input file will be types::TY_PP_ASM for a 
>> caller other than ClangAs?
>> - If not, why not?
>> - If so, this looks like a behaviour change.  Is that a bugfix, or a new bug?
> 
> I'm not sure. I'll try and come up with a test that exposes a behavior change.

Okay, great.

> 
>> 
> +  }
> +
> if (CCCPrintBindings && !CCGenDiagnostics) {
> +// FIXME: We should be able to use the effective triple here, but 
> doing so
> +// breaks some multi-arch tests.
 
 This is interesting.  Why does it break the tests?
>>> 
>>> It breaks these two tests:
>>> 
>>> test/Driver/darwin-dsymutil.c
>>> test/Driver/darwin-debug-version.c
>>> 
>>> The tests expect "-ccc-print-bindings" to spit out a default triple, namely:
>>> 
>>> x86_64-apple-darwin10
>>> 
>>> Printing out the effective triple means we get this instead:
>>> 
>>> x86_64-apple-macosx10.6.0
>>> 
>>> There's some chance that the test is too strict. I'm planning on keeping 
>>> this
>>> patch NFCI and following up with the test authors later.
>> 
>> SGTM.
>> 
 
>   llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
><< " - \"" << T->getName() << "\", inputs: [";
>   for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
> @@ -2122,7 +2136,7 @@
>   }
>   llvm::errs() << "], output: " << Result.getAsString() << "\n";
> } else {
> -T->ConstructJob(C, *JA, Result, InputInfos,
> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>   C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
 
 Why doesn't this have the same problem as above?  I.e., what happens for
 multi-arch cases?
>>> 
>>> Methods which override ConstructJob used to call ComputeEffectiveClangTriple
>>> themselves, so they "expect" effective triples.
>> 
>> Rather than adding the effective triple to all the argument lists, does it 
>> make sense to call T->setEffectiveTriple() or 
>> 

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 12, 2016, at 6:23 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2016-Jul-12, at 17:47, Vedant Kumar  wrote:
>> 
>> 
>>> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
>>> wrote:
>>> 
>>> 
 On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
 
 vsk created this revision.
 vsk added a reviewer: dexonsmith.
 vsk added a subscriber: cfe-commits.
 Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
 
 Compute an effective target triple exactly once in ConstructJob(), and
 then simply pass around const references to it. This eliminates wasteful
 re-computation of effective triples (e.g in getARMFloatABI()).
 
 http://reviews.llvm.org/D22290
 
 Files:
 include/clang/Driver/SanitizerArgs.h
 include/clang/Driver/Tool.h
 include/clang/Driver/ToolChain.h
 lib/Driver/Driver.cpp
 lib/Driver/SanitizerArgs.cpp
 lib/Driver/ToolChain.cpp
 lib/Driver/ToolChains.cpp
 lib/Driver/ToolChains.h
 lib/Driver/Tools.cpp
 lib/Driver/Tools.h
 
 
>>> 
 Index: lib/Driver/Driver.cpp
 ===
 --- lib/Driver/Driver.cpp
 +++ lib/Driver/Driver.cpp
 @@ -2112,7 +2112,21 @@
 AtTopLevel, MultipleArchs),
   BaseInput);
 
 +  llvm::Triple EffectiveTriple;
 +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
 +  if (InputInfos.size() != 1) {
 +EffectiveTriple = llvm::Triple(
 +T->getToolChain().ComputeEffectiveClangTriple(Args));
 +  } else {
 +// Pass along the input type if it can be unambiguously determined.
 +EffectiveTriple =
 +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
 +Args, InputInfos[0].getType()));
> 
> It looks to me like this could call InputInfos[0].getType() and pass it into 
> ComputeEffectiveClangTriple in cases where previously the type-less overload 
> (which defaults to types::TY_Invalid) would have been called.

You're right that this is a behavior change!

The site you identified below (in ComputeLLVMTriple()) looks like the only
place where ComputeEffectiveClangTriple's output is affected by InputType.

> 
> Previously, the type was only specified in ClangAs::ConstructJob.  It only 
> seems to make a difference for this logic in ToolChain::ComputeLLVMTriple:
> 
> if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
>  options::OPT_mno_thumb, ThumbDefault)) || IsMProfile) {
>   if (IsBigEndian)
> ArchName = "thumbeb";
>   else
> ArchName = "thumb";
> }
> 
> Is it possible that a single input file will be types::TY_PP_ASM for a caller 
> other than ClangAs?
> - If not, why not?
> - If so, this looks like a behaviour change.  Is that a bugfix, or a new bug?

I'm not sure. I'll try and come up with a test that exposes a behavior change.


> 
 +  }
 +
  if (CCCPrintBindings && !CCGenDiagnostics) {
 +// FIXME: We should be able to use the effective triple here, but 
 doing so
 +// breaks some multi-arch tests.
>>> 
>>> This is interesting.  Why does it break the tests?
>> 
>> It breaks these two tests:
>> 
>>  test/Driver/darwin-dsymutil.c
>>  test/Driver/darwin-debug-version.c
>> 
>> The tests expect "-ccc-print-bindings" to spit out a default triple, namely:
>> 
>>  x86_64-apple-darwin10
>> 
>> Printing out the effective triple means we get this instead:
>> 
>>  x86_64-apple-macosx10.6.0
>> 
>> There's some chance that the test is too strict. I'm planning on keeping this
>> patch NFCI and following up with the test authors later.
> 
> SGTM.
> 
>>> 
llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
 << " - \"" << T->getName() << "\", inputs: [";
for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
 @@ -2122,7 +2136,7 @@
}
llvm::errs() << "], output: " << Result.getAsString() << "\n";
  } else {
 -T->ConstructJob(C, *JA, Result, InputInfos,
 +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
>>> 
>>> Why doesn't this have the same problem as above?  I.e., what happens for
>>> multi-arch cases?
>> 
>> Methods which override ConstructJob used to call ComputeEffectiveClangTriple
>> themselves, so they "expect" effective triples.
> 
> Rather than adding the effective triple to all the argument lists, does it 
> make sense to call T->setEffectiveTriple() or 
> T->computeEffectiveTriple(DefaultTriple)?

This gets a bit hairy because a Tool or ToolChain can outlive a single call to
BuildJobsForActionNoCache(). That makes it hard to figure out exactly when a
triple stored within one of these 

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Jul-12, at 17:47, Vedant Kumar  wrote:
> 
> 
>> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> 
>>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>>> 
>>> vsk created this revision.
>>> vsk added a reviewer: dexonsmith.
>>> vsk added a subscriber: cfe-commits.
>>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>>> 
>>> Compute an effective target triple exactly once in ConstructJob(), and
>>> then simply pass around const references to it. This eliminates wasteful
>>> re-computation of effective triples (e.g in getARMFloatABI()).
>>> 
>>> http://reviews.llvm.org/D22290
>>> 
>>> Files:
>>> include/clang/Driver/SanitizerArgs.h
>>> include/clang/Driver/Tool.h
>>> include/clang/Driver/ToolChain.h
>>> lib/Driver/Driver.cpp
>>> lib/Driver/SanitizerArgs.cpp
>>> lib/Driver/ToolChain.cpp
>>> lib/Driver/ToolChains.cpp
>>> lib/Driver/ToolChains.h
>>> lib/Driver/Tools.cpp
>>> lib/Driver/Tools.h
>>> 
>>> 
>> 
>>> Index: lib/Driver/Driver.cpp
>>> ===
>>> --- lib/Driver/Driver.cpp
>>> +++ lib/Driver/Driver.cpp
>>> @@ -2112,7 +2112,21 @@
>>> AtTopLevel, MultipleArchs),
>>>   BaseInput);
>>> 
>>> +  llvm::Triple EffectiveTriple;
>>> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
>>> +  if (InputInfos.size() != 1) {
>>> +EffectiveTriple = llvm::Triple(
>>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>>> +  } else {
>>> +// Pass along the input type if it can be unambiguously determined.
>>> +EffectiveTriple =
>>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>>> +Args, InputInfos[0].getType()));

It looks to me like this could call InputInfos[0].getType() and pass it into 
ComputeEffectiveClangTriple in cases where previously the type-less overload 
(which defaults to types::TY_Invalid) would have been called.

Previously, the type was only specified in ClangAs::ConstructJob.  It only 
seems to make a difference for this logic in ToolChain::ComputeLLVMTriple:

if ((InputType != types::TY_PP_Asm && Args.hasFlag(options::OPT_mthumb,
 options::OPT_mno_thumb, ThumbDefault)) || IsMProfile) {
  if (IsBigEndian)
ArchName = "thumbeb";
  else
ArchName = "thumb";
}

Is it possible that a single input file will be types::TY_PP_ASM for a caller 
other than ClangAs?
- If not, why not?
- If so, this looks like a behaviour change.  Is that a bugfix, or a new bug?

>>> +  }
>>> +
>>>  if (CCCPrintBindings && !CCGenDiagnostics) {
>>> +// FIXME: We should be able to use the effective triple here, but 
>>> doing so
>>> +// breaks some multi-arch tests.
>> 
>> This is interesting.  Why does it break the tests?
> 
> It breaks these two tests:
> 
>  test/Driver/darwin-dsymutil.c
>  test/Driver/darwin-debug-version.c
> 
> The tests expect "-ccc-print-bindings" to spit out a default triple, namely:
> 
>  x86_64-apple-darwin10
> 
> Printing out the effective triple means we get this instead:
> 
>  x86_64-apple-macosx10.6.0
> 
> There's some chance that the test is too strict. I'm planning on keeping this
> patch NFCI and following up with the test authors later.

SGTM.

>> 
>>>llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>>> << " - \"" << T->getName() << "\", inputs: [";
>>>for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
>>> @@ -2122,7 +2136,7 @@
>>>}
>>>llvm::errs() << "], output: " << Result.getAsString() << "\n";
>>>  } else {
>>> -T->ConstructJob(C, *JA, Result, InputInfos,
>>> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>>>C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
>> 
>> Why doesn't this have the same problem as above?  I.e., what happens for
>> multi-arch cases?
> 
> Methods which override ConstructJob used to call ComputeEffectiveClangTriple
> themselves, so they "expect" effective triples.

Rather than adding the effective triple to all the argument lists, does it make 
sense to call T->setEffectiveTriple() or 
T->computeEffectiveTriple(DefaultTriple)?  Maybe it doesn't matter either way, 
since Tool isn't really used for anything else...

> 
>> 
>>>  }
>>>  return Result;
>>> 
>> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 12, 2016, at 5:47 PM, Vedant Kumar via cfe-commits 
>  wrote:
> 
>> 
>> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> 
>>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>>> 
>>> vsk created this revision.
>>> vsk added a reviewer: dexonsmith.
>>> vsk added a subscriber: cfe-commits.
>>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>>> 
>>> Compute an effective target triple exactly once in ConstructJob(), and
>>> then simply pass around const references to it. This eliminates wasteful
>>> re-computation of effective triples (e.g in getARMFloatABI()).
>>> 
>>> http://reviews.llvm.org/D22290
>>> 
>>> Files:
>>> include/clang/Driver/SanitizerArgs.h
>>> include/clang/Driver/Tool.h
>>> include/clang/Driver/ToolChain.h
>>> lib/Driver/Driver.cpp
>>> lib/Driver/SanitizerArgs.cpp
>>> lib/Driver/ToolChain.cpp
>>> lib/Driver/ToolChains.cpp
>>> lib/Driver/ToolChains.h
>>> lib/Driver/Tools.cpp
>>> lib/Driver/Tools.h
>>> 
>>> 
>> 
>>> Index: lib/Driver/Driver.cpp
>>> ===
>>> --- lib/Driver/Driver.cpp
>>> +++ lib/Driver/Driver.cpp
>>> @@ -2112,7 +2112,21 @@
>>> AtTopLevel, MultipleArchs),
>>>   BaseInput);
>>> 
>>> +  llvm::Triple EffectiveTriple;
>>> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
>>> +  if (InputInfos.size() != 1) {
>>> +EffectiveTriple = llvm::Triple(
>>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>>> +  } else {
>>> +// Pass along the input type if it can be unambiguously determined.
>>> +EffectiveTriple =
>>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>>> +Args, InputInfos[0].getType()));
>>> +  }
>>> +
>>>  if (CCCPrintBindings && !CCGenDiagnostics) {
>>> +// FIXME: We should be able to use the effective triple here, but 
>>> doing so
>>> +// breaks some multi-arch tests.
>> 
>> This is interesting.  Why does it break the tests?
> 
> It breaks these two tests:
> 
>  test/Driver/darwin-dsymutil.c
>  test/Driver/darwin-debug-version.c
> 
> The tests expect "-ccc-print-bindings" to spit out a default triple, namely:
> 
>  x86_64-apple-darwin10
> 
> Printing out the effective triple means we get this instead:
> 
>  x86_64-apple-macosx10.6.0
> 
> There's some chance that the test is too strict. I'm planning on keeping this
> patch NFCI and following up with the test authors later.
> 
> thanks,
> vedant
> 
>> 
>>>llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>>> << " - \"" << T->getName() << "\", inputs: [";
>>>for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
>>> @@ -2122,7 +2136,7 @@
>>>}
>>>llvm::errs() << "], output: " << Result.getAsString() << "\n";
>>>  } else {
>>> -T->ConstructJob(C, *JA, Result, InputInfos,
>>> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>>>C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
>> 
>> Why doesn't this have the same problem as above?  I.e., what happens for
>> multi-arch cases?
> 
> Methods which override ConstructJob used to call ComputeEffectiveClangTriple
> themselves, so they "expect" effective triples.

^ Er, I meant: methods which override or are called by ConstructJob() expect
effective triples.

This patch consolidates all calls to ComputeEffectiveClangTriple() into this
one site.

vedant

> 
>> 
>>>  }
>>>  return Result;
>>> 
>> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

> On Jul 12, 2016, at 5:41 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> 
>> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
>> 
>> vsk created this revision.
>> vsk added a reviewer: dexonsmith.
>> vsk added a subscriber: cfe-commits.
>> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
>> 
>> Compute an effective target triple exactly once in ConstructJob(), and
>> then simply pass around const references to it. This eliminates wasteful
>> re-computation of effective triples (e.g in getARMFloatABI()).
>> 
>> http://reviews.llvm.org/D22290
>> 
>> Files:
>> include/clang/Driver/SanitizerArgs.h
>> include/clang/Driver/Tool.h
>> include/clang/Driver/ToolChain.h
>> lib/Driver/Driver.cpp
>> lib/Driver/SanitizerArgs.cpp
>> lib/Driver/ToolChain.cpp
>> lib/Driver/ToolChains.cpp
>> lib/Driver/ToolChains.h
>> lib/Driver/Tools.cpp
>> lib/Driver/Tools.h
>> 
>> 
> 
>> Index: lib/Driver/Driver.cpp
>> ===
>> --- lib/Driver/Driver.cpp
>> +++ lib/Driver/Driver.cpp
>> @@ -2112,7 +2112,21 @@
>>  AtTopLevel, MultipleArchs),
>>BaseInput);
>> 
>> +  llvm::Triple EffectiveTriple;
>> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
>> +  if (InputInfos.size() != 1) {
>> +EffectiveTriple = llvm::Triple(
>> +T->getToolChain().ComputeEffectiveClangTriple(Args));
>> +  } else {
>> +// Pass along the input type if it can be unambiguously determined.
>> +EffectiveTriple =
>> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
>> +Args, InputInfos[0].getType()));
>> +  }
>> +
>>   if (CCCPrintBindings && !CCGenDiagnostics) {
>> +// FIXME: We should be able to use the effective triple here, but doing 
>> so
>> +// breaks some multi-arch tests.
> 
> This is interesting.  Why does it break the tests?

It breaks these two tests:

  test/Driver/darwin-dsymutil.c
  test/Driver/darwin-debug-version.c

The tests expect "-ccc-print-bindings" to spit out a default triple, namely:

  x86_64-apple-darwin10

Printing out the effective triple means we get this instead:

  x86_64-apple-macosx10.6.0

There's some chance that the test is too strict. I'm planning on keeping this
patch NFCI and following up with the test authors later.

thanks,
vedant

> 
>> llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>>  << " - \"" << T->getName() << "\", inputs: [";
>> for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
>> @@ -2122,7 +2136,7 @@
>> }
>> llvm::errs() << "], output: " << Result.getAsString() << "\n";
>>   } else {
>> -T->ConstructJob(C, *JA, Result, InputInfos,
>> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>> C.getArgsForToolChain(TC, BoundArch), LinkingOutput);
> 
> Why doesn't this have the same problem as above?  I.e., what happens for
> multi-arch cases?

Methods which override ConstructJob used to call ComputeEffectiveClangTriple
themselves, so they "expect" effective triples.

> 
>>   }
>>   return Result;
>> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Duncan P. N. Exon Smith via cfe-commits]

> On 2016-Jul-12, at 16:53, Vedant Kumar  wrote:
> 
> vsk created this revision.
> vsk added a reviewer: dexonsmith.
> vsk added a subscriber: cfe-commits.
> Herald added subscribers: srhines, danalbert, tberghammer, aemerson.
> 
> Compute an effective target triple exactly once in ConstructJob(), and
> then simply pass around const references to it. This eliminates wasteful
> re-computation of effective triples (e.g in getARMFloatABI()).
> 
> http://reviews.llvm.org/D22290
> 
> Files:
>  include/clang/Driver/SanitizerArgs.h
>  include/clang/Driver/Tool.h
>  include/clang/Driver/ToolChain.h
>  lib/Driver/Driver.cpp
>  lib/Driver/SanitizerArgs.cpp
>  lib/Driver/ToolChain.cpp
>  lib/Driver/ToolChains.cpp
>  lib/Driver/ToolChains.h
>  lib/Driver/Tools.cpp
>  lib/Driver/Tools.h
> 
> 

> Index: lib/Driver/Driver.cpp
> ===
> --- lib/Driver/Driver.cpp
> +++ lib/Driver/Driver.cpp
> @@ -2112,7 +2112,21 @@
>   AtTopLevel, MultipleArchs),
> BaseInput);
>  
> +  llvm::Triple EffectiveTriple;
> +  const ArgList  = C.getArgsForToolChain(TC, BoundArch);
> +  if (InputInfos.size() != 1) {
> +EffectiveTriple = llvm::Triple(
> +T->getToolChain().ComputeEffectiveClangTriple(Args));
> +  } else {
> +// Pass along the input type if it can be unambiguously determined.
> +EffectiveTriple =
> +llvm::Triple(T->getToolChain().ComputeEffectiveClangTriple(
> +Args, InputInfos[0].getType()));
> +  }
> +
>if (CCCPrintBindings && !CCGenDiagnostics) {
> +// FIXME: We should be able to use the effective triple here, but doing 
> so
> +// breaks some multi-arch tests.

This is interesting.  Why does it break the tests?

>  llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
>   << " - \"" << T->getName() << "\", inputs: [";
>  for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
> @@ -2122,7 +2136,7 @@
>  }
>  llvm::errs() << "], output: " << Result.getAsString() << "\n";
>} else {
> -T->ConstructJob(C, *JA, Result, InputInfos,
> +T->ConstructJob(C, *JA, Result, InputInfos, EffectiveTriple,
>  C.getArgsForToolChain(TC, BoundArch), LinkingOutput);

Why doesn't this have the same problem as above?  I.e., what happens for
multi-arch cases?

>}
>return Result;
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D22290: [PATCH 2/2] [Driver] Compute effective target triples once per job (NFCI)

[Vedant Kumar via cfe-commits]

vsk created this revision.
vsk added a reviewer: dexonsmith.
vsk added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert, tberghammer, aemerson.

Compute an effective target triple exactly once in ConstructJob(), and
then simply pass around const references to it. This eliminates wasteful
re-computation of effective triples (e.g in getARMFloatABI()).

http://reviews.llvm.org/D22290

Files:
  include/clang/Driver/SanitizerArgs.h
  include/clang/Driver/Tool.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Driver.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h

Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -60,7 +60,8 @@
const InputInfoList ,
const ToolChain *AuxToolChain) const;
 
-  void AddAArch64TargetArgs(const llvm::opt::ArgList ,
+  void AddAArch64TargetArgs(const llvm::Triple ,
+const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const;
   void AddARMTargetArgs(const llvm::Triple ,
 const llvm::opt::ArgList ,
@@ -115,6 +116,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -132,6 +134,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -159,6 +162,7 @@
   bool hasIntegratedAssembler() const override { return true; }
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 
@@ -218,6 +222,7 @@
llvm::opt::ArgStringList ) const;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -233,6 +238,7 @@
llvm::opt::ArgStringList ) const;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -247,6 +253,7 @@
   bool hasIntegratedCPP() const override { return false; }
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -262,6 +269,7 @@
   bool hasIntegratedCPP() const override;
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -323,6 +331,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -362,6 +371,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -382,6 +392,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -394,6 +405,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const llvm::Triple ,
 const llvm::opt::ArgList ,
 const char *LinkingOutput) const override;
 };
@@ -408,6 +420,7 @@
 
   void ConstructJob(Compilation , const JobAction ,
 const InputInfo , const InputInfoList ,
+const