Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-15 Thread Teresa Johnson via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL250398: Clang support for -flto=thin. (authored by 
tejohnson).

Changed prior to commit:
  http://reviews.llvm.org/D11908?vs=36453=37478#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D11908

Files:
  cfe/trunk/include/clang/Driver/Driver.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/clang_f_opts.c
  cfe/trunk/test/Driver/lto.c
  cfe/trunk/test/Driver/thinlto.c
  cfe/trunk/test/Misc/thinlto.c

Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -687,9 +687,12 @@
 def flat__namespace : Flag<["-"], "flat_namespace">;
 def flax_vector_conversions : Flag<["-"], "flax-vector-conversions">, Group;
 def flimited_precision_EQ : Joined<["-"], "flimited-precision=">, Group;
-def flto_EQ : Joined<["-"], "flto=">, Group;
-def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group;
-def fno_lto : Flag<["-"], "fno-lto">, Group;
+def flto_EQ : Joined<["-"], "flto=">, Flags<[CC1Option]>, Group,
+  HelpText<"Set LTO mode to either 'full' or 'thin'">;
+def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group,
+  HelpText<"Enable LTO in 'full' mode">;
+def fno_lto : Flag<["-"], "fno-lto">, Group,
+  HelpText<"Disable LTO mode (default)">;
 def fmacro_backtrace_limit_EQ : Joined<["-"], "fmacro-backtrace-limit=">,
 Group, Flags<[DriverOption, CoreOption]>;
 def fmerge_all_constants : Flag<["-"], "fmerge-all-constants">, Group;
Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -52,6 +52,14 @@
   class SanitizerArgs;
   class ToolChain;
 
+/// Describes the kind of LTO mode selected via -f(no-)?lto(=.*)? options.
+enum LTOKind {
+  LTOK_None,
+  LTOK_Full,
+  LTOK_Thin,
+  LTOK_Unknown
+};
+
 /// Driver - Encapsulate logic for constructing compilation processes
 /// from a set of gcc-driver-like command line arguments.
 class Driver {
@@ -74,6 +82,9 @@
 SaveTempsObj
   } SaveTemps;
 
+  /// LTO mode selected via -f(no-)?lto(=.*)? options.
+  LTOKind LTOMode;
+
 public:
   // Diag - Forwarding function for diagnostics.
   DiagnosticBuilder Diag(unsigned DiagID) const {
@@ -411,9 +422,17 @@
   /// handle this action.
   bool ShouldUseClangCompiler(const JobAction ) const;
 
-  bool IsUsingLTO(const llvm::opt::ArgList ) const;
+  /// Returns true if we are performing any kind of LTO.
+  bool isUsingLTO() const { return LTOMode != LTOK_None; }
+
+  /// Get the specific kind of LTO being performed.
+  LTOKind getLTOMode() const { return LTOMode; }
 
 private:
+  /// Parse the \p Args list for LTO options and record the type of LTO
+  /// compilation based on which -f(no-)?lto(=.*)? option occurs last.
+  void setLTOMode(const llvm::opt::ArgList );
+
   /// \brief Retrieves a ToolChain for a particular \p Target triple.
   ///
   /// Will cache ToolChains for the life of the driver object, and create them
Index: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
===
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def
@@ -73,6 +73,8 @@
  ///< be generated.
 CODEGENOPT(PrepareForLTO , 1, 0) ///< Set when -flto is enabled on the
  ///< compile step.
+CODEGENOPT(EmitFunctionSummary, 1, 0) ///< Set when -flto=thin is enabled on the
+  ///< compile step.
 CODEGENOPT(MergeAllConstants , 1, 1) ///< Merge identical constants.
 CODEGENOPT(MergeFunctions, 1, 0) ///< Set when -fmerge-functions is enabled.
 CODEGENOPT(MSVolatile, 1, 0) ///< Set when /volatile:ms is enabled.
Index: cfe/trunk/test/Misc/thinlto.c
===
--- cfe/trunk/test/Misc/thinlto.c
+++ cfe/trunk/test/Misc/thinlto.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -flto=thin -emit-llvm-bc < %s | llvm-bcanalyzer -dump | FileCheck %s
+// CHECK:  %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
-
-// RUN: %clang -ccc-print-phases %s -flto 2> %t.log
-// RUN: grep '0: input, ".*lto.c", c' %t.log
-// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
-// RUN: grep '4: linker, {3}, image' %t.log
+// RUN: %clang -ccc-print-phases -c %s -flto 2>

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-14 Thread Teresa Johnson via cfe-commits 
Ping.
Thanks,
Teresa

On Sat, Oct 3, 2015 at 6:51 PM, Teresa Johnson  wrote:
> tejohnson updated this revision to Diff 36453.
> tejohnson added a comment.
>
> - Rename code gen option to EmitFunctionSummary as per review for 
> http://reviews.llvm.org/D13107.
> - Clang format the latest changes.
>
>   Let me know if it looks good now.
>
>
> http://reviews.llvm.org/D11908
>
> Files:
>   include/clang/Driver/Driver.h
>   include/clang/Driver/Options.td
>   include/clang/Frontend/CodeGenOptions.def
>   lib/CodeGen/BackendUtil.cpp
>   lib/Driver/Driver.cpp
>   lib/Driver/SanitizerArgs.cpp
>   lib/Driver/Tools.cpp
>   lib/Frontend/CompilerInvocation.cpp
>   test/Driver/clang_f_opts.c
>   test/Driver/lto.c
>   test/Driver/thinlto.c
>   test/Misc/thinlto.c
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-14 Thread Mehdi AMINI via cfe-commits 
joker.eph accepted this revision.
joker.eph added a comment.
This revision is now accepted and ready to land.

LGTM


http://reviews.llvm.org/D11908



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

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-03 Thread Teresa Johnson via cfe-commits 
tejohnson updated this revision to Diff 36453.
tejohnson added a comment.

- Rename code gen option to EmitFunctionSummary as per review for 
http://reviews.llvm.org/D13107.
- Clang format the latest changes.

  Let me know if it looks good now.


http://reviews.llvm.org/D11908

Files:
  include/clang/Driver/Driver.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/BackendUtil.cpp
  lib/Driver/Driver.cpp
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/clang_f_opts.c
  test/Driver/lto.c
  test/Driver/thinlto.c
  test/Misc/thinlto.c

Index: test/Misc/thinlto.c
===
--- /dev/null
+++ test/Misc/thinlto.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -flto=thin -emit-llvm-bc < %s | llvm-bcanalyzer -dump | FileCheck %s
+// CHECK:  %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILE-ACTIONS < %t %s
+//
+// CHECK-COMPILE-ACTIONS: 2: compiler, {1}, ir
+// CHECK-COMPILE-ACTIONS: 3: backend, {2}, lto-bc
+
+// RUN: %clang -ccc-print-phases %s -flto=thin 2> %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILELINK-ACTIONS < %t %s
+//
+// CHECK-COMPILELINK-ACTIONS: 0: input, "{{.*}}thinlto.c", c
+// CHECK-COMPILELINK-ACTIONS: 1: preprocessor, {0}, cpp-output
+// CHECK-COMPILELINK-ACTIONS: 2: compiler, {1}, ir
+// CHECK-COMPILELINK-ACTIONS: 3: backend, {2}, lto-bc
+// CHECK-COMPILELINK-ACTIONS: 4: linker, {3}, image
+
+// -flto=thin should cause link using gold plugin with thinlto option,
+// also confirm that it takes precedence over earlier -fno-lto and -flto=full.
+// RUN: %clang -### %s -flto=full -fno-lto -flto=thin 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-THIN-ACTION < %t %s
+//
+// CHECK-LINK-THIN-ACTION: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-LINK-THIN-ACTION: "-plugin-opt=thinlto"
+
+// Check that subsequent -flto=full takes precedence
+// RUN: %clang -### %s -flto=thin -flto=full 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-FULL-ACTION < %t %s
+//
+// CHECK-LINK-FULL-ACTION: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-LINK-FULL-ACTION-NOT: "-plugin-opt=thinlto"
+
+// Check that subsequent -fno-lto takes precedence
+// RUN: %clang -### %s -flto=thin -fno-lto 2> %t
+// RUN: FileCheck -check-prefix=CHECK-LINK-NOLTO-ACTION < %t %s
+//
+// CHECK-LINK-NOLTO-ACTION-NOT: "-plugin" "{{.*}}/LLVMgold.so"
+// CHECK-LINK-NOLTO-ACTION-NOT: "-plugin-opt=thinlto"
Index: test/Driver/lto.c
===
--- test/Driver/lto.c
+++ test/Driver/lto.c
@@ -1,25 +1,51 @@
 // -flto causes a switch to llvm-bc object files.
-// RUN: %clang -ccc-print-phases -c %s -flto 2> %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
+// RUN: %clang -ccc-print-phases -c %s -flto 2> %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILE-ACTIONS < %t %s
+//
+// CHECK-COMPILE-ACTIONS: 2: compiler, {1}, ir
+// CHECK-COMPILE-ACTIONS: 3: backend, {2}, lto-bc
 
-// RUN: %clang -ccc-print-phases %s -flto 2> %t.log
-// RUN: grep '0: input, ".*lto.c", c' %t.log
-// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
-// RUN: grep '2: compiler, {1}, ir' %t.log
-// RUN: grep '3: backend, {2}, lto-bc' %t.log
-// RUN: grep '4: linker, {3}, image' %t.log
+// RUN: %clang -ccc-print-phases %s -flto 2> %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILELINK-ACTIONS < %t %s
+//
+// CHECK-COMPILELINK-ACTIONS: 0: input, "{{.*}}lto.c", c
+// CHECK-COMPILELINK-ACTIONS: 1: preprocessor, {0}, cpp-output
+// CHECK-COMPILELINK-ACTIONS: 2: compiler, {1}, ir
+// CHECK-COMPILELINK-ACTIONS: 3: backend, {2}, lto-bc
+// CHECK-COMPILELINK-ACTIONS: 4: linker, {3}, image
 
 // llvm-bc and llvm-ll outputs need to match regular suffixes
 // (unfortunately).
-// RUN: %clang %s -flto -save-temps -### 2> %t.log
-// RUN: grep '"-o" ".*lto\.i" "-x" "c" ".*lto\.c"' %t.log
-// RUN: grep '"-o" ".*lto\.bc" .*".*lto\.i"' %t.log
-// RUN: grep '"-o" ".*lto\.o" .*".*lto\.bc"' %t.log
-// RUN: grep '".*a\.\(out\|exe\)" .*".*lto\.o"' %t.log
+// RUN: %clang %s -flto -save-temps -### 2> %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILELINK-SUFFIXES < %t %s
+//
+// CHECK-COMPILELINK-SUFFIXES: "-o" "{{.*}}lto.i" "-x" "c" "{{.*}}lto.c"
+// CHECK-COMPILELINK-SUFFIXES: "-o" "{{.*}}lto.bc" {{.*}}"{{.*}}lto.i"
+// CHECK-COMPILELINK-SUFFIXES: "-o" "{{.*}}lto.o" {{.*}}"{{.*}}lto.bc"
+// CHECK-COMPILELINK-SUFFIXES: "{{.*}}a.{{(out|exe)}}" {{.*}}"{{.*}}lto.o"
 
-// RUN: %clang %s -flto -S -### 2> %t.log
-// RUN: grep '"-o" ".*lto\.s" "-x" "c" ".*lto\.c"' %t.log
+// RUN: %clang %s -flto -S -### 2> %t
+// RUN: FileCheck -check-prefix=CHECK-COMPILE-SUFFIXES < %t %s
+//
+// CHECK-COMPILE-SUFFIXES: "-o" "{{.*}}lto.s" "-x" "c" "{{.*}}lto.c"
 
 // RUN: not %clang %s -emit-llvm 2>&1 | FileCheck --check-prefix=LLVM-LINK %s
 // LLVM-LINK: -emit-llvm cannot be used when linking
+
+// -flto should cause link using gold plugin
+// RUN: %clang -### %s -flto 2> %t
+// RUN:

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-02 Thread Teresa Johnson via cfe-commits 
tejohnson added a comment.

Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi for 
some reason. Trying again...

In http://reviews.llvm.org/D11908#258540, @klimek wrote:

> Perhaps "sharded" would fit what it is?


You could have a sharded mode for full FDO (like gcc's partitioned LTO). And we 
aren't really making any explicit sharding decisions, since the backends do 
importing on demand.

As David mentioned, "inlineonly" is much too restrictive for what is possible. 
I prefer to stick with "thin" since it refers to this new model of keeping the 
whole program part very thin.

Does anyone have an opinion on "full" vs "monolithic" vs something else for the 
traditional full/monolithic LTO?


http://reviews.llvm.org/D11908



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

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-02 Thread Duncan P. N. Exon Smith via cfe-commits 

> On 2015-Oct-02, at 08:59, Teresa Johnson  wrote:
> 
> On Fri, Oct 2, 2015 at 8:53 AM, Manuel Klimek  wrote:
>> klimek added a comment.
>> 
>> In http://reviews.llvm.org/D11908#258570, @tejohnson wrote:
>> 
>>> Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi 
>>> for some reason. Trying again...
>>> 
>>> In http://reviews.llvm.org/D11908#258540, @klimek wrote:
>>> 
 Perhaps "sharded" would fit what it is?
>>> 
>>> 
>>> You could have a sharded mode for full FDO (like gcc's partitioned LTO). 
>>> And we aren't really making any explicit sharding decisions, since the 
>>> backends do importing on demand.
>>> 
>>> As David mentioned, "inlineonly" is much too restrictive for what is 
>>> possible. I prefer to stick with "thin" since it refers to this new model 
>>> of keeping the whole program part very thin.
>>> 
>>> Does anyone have an opinion on "full" vs "monolithic" vs something else for 
>>> the traditional full/monolithic LTO?
>> 
>> 
>> If "sharded" is not the right term, than "monolithic" doesn't seem like the 
>> right term, either, right?
> 
> Right, LLVM's "full" LTO could move to a partitioned/sharded model as
> well. That is more of an implementation issue, not related to the
> model.
> 
>> 
>> If "thin" basically refers to how much information is given to the lto steps 
>> (for which "thin" seems to be a good name actually), then "full" seems to be 
>> a good term for the, well, full information.
> 
> Ok, thanks. That echos my thinking.
> 

I'm fine with "full".

> Teresa
> 
>> 
>> 
>> http://reviews.llvm.org/D11908
>> 
>> 
>> 
> 
> 
> 
> -- 
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

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

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-10-01 Thread Teresa Johnson via cfe-commits 
On Wed, Sep 30, 2015 at 2:33 PM, Duncan P. N. Exon Smith
 wrote:
> +echristo, +espindola, +pcc
>
>> On 2015-Sep-30, at 12:39, Teresa Johnson  wrote:
>>
>> On Wed, Sep 30, 2015 at 11:11 AM, Duncan P. N. Exon Smith
>>  wrote:
>>>
 On 2015-Sep-30, at 10:40, Teresa Johnson  wrote:

 On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith
  wrote:
>
>> On 2015-Sep-23, at 10:28, Teresa Johnson  wrote:
>>
>> Index: include/clang/Driver/Options.td
>> ===
>> --- include/clang/Driver/Options.td
>> +++ include/clang/Driver/Options.td
>> @@ -686,6 +686,9 @@
>> def flto_EQ : Joined<["-"], "flto=">, 
>> Group;
>> def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group;
>> def fno_lto : Flag<["-"], "fno-lto">, Group;
>> +def fthinlto : Flag<["-"], "fthinlto">, Flags<[CC1Option]>, 
>> Group;
>
> I wonder whether this is the right way to add new variants of LTO.
> I.e., maybe this should be "-flto=thin"?  Do you happen to know how this
> would conflict with GCC options?  (I see we ignore "-flto="...)

 I looked at GCC docs and sources. It does have a -flto= variant. From
 https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:
 -
 If you specify the optional n, the optimization and code generation
 done at link time is executed in parallel using n parallel jobs by
 utilizing an installed make program. The environment variable MAKE may
 be used to override the program used. The default value for n is 1.

 You can also specify -flto=jobserver to use GNU make's job server mode
 to determine the number of parallel jobs. This is useful when the
 Makefile calling GCC is already executing in parallel. You must
 prepend a ‘+’ to the command recipe in the parent Makefile for this to
 work. This option likely only works if MAKE is GNU make.
 

 I would anticipate that we may want to support something like this for
 ThinLTO eventually to specify the number of parallel jobs for the
 ThinLTO backend processes. So it might be confusing to overload
 -flto=.
>>>
>>> Hmm.  You're right that the GCC usage seems pretty different.
>>>
>>> I guess you're envisioning -fthinlto=jobserver?
>>
>> Or -fthinlto=n.
>>
>>> I wonder if we could
>>> do this as -flto=thin,jobserver or something similar?
>>
>> I am ok with -flto=thin and then later extending to -flto=thin,n etc.
>>
>> This simplifies the interaction with -fno-lto.
>>
>> I think a -flto=thin followed by -flto should probably revert to
>> normal LTO, WDYT?
>>
>> Another thing to consider is to add -flto=full or something like that
>> which is currently an alias for -flto. So we would have:
>>
>> -flto= where type could be "full" or "thin"
>> -flto means -flto=full
>> -fno-lto disables all types of flto
>> and last option of the above 3 wins.
>
> This SGTM.  "monolithic" might be more descriptive than "full", or
> maybe someone has a better name.
>
> Eric/Rafael/Peter: any thoughts about driver options?

For now I have implemented -flto=full and -flto=thin. I guess "full"
is easier to type than "monolithic", but I am fine with switching it
to the latter or any better suggestions. I am about to post the new
patch.

>
>>>
>>> It's pretty hard to remove driver options, so I think it's important to
>>> get the interface right.  I anticipate that we'll add more LTO variants
>>> in the future, so we should take care that this scales reasonably.
>>>
>>> (This may be a good discussion for cfe-dev, not sure.)
>>>
> E.g., as a user I'd expect -fno-lto to turn off whatever LTO was turned
> on.  And I might expect -flto to override -fthinlto, or vice versa.

 Good point, I think the last one should win. Looks like right now
 -fthinlto is effectively always winning. I will fix that.

 Not sure about -fno-lto behavior if we leave -fthinlto as a separate
 option. Let me know what you think based on the GCC usage of -flto=.
>>>
>>> Right, if they're totally separate, then either behaviour for -fno-lto
>>> is confusing.
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-09-30 Thread Teresa Johnson via cfe-commits 
On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith
 wrote:
>
>> On 2015-Sep-23, at 10:28, Teresa Johnson  wrote:
>>
>> tejohnson updated this revision to Diff 35527.
>> tejohnson added a comment.
>>
>> Updated the patch for the new LLVM/gold patch 
>> (http://reviews.llvm.org/D13107).
>>
>> Two changes:
>>
>> - I put back the original change to pass a new plugin option to gold. Since 
>> the function index design/name has been generalized to not be 
>> ThinLTO-specific, it makes sense to have the ThinLTO-related gold behavior 
>> for modules with those sections to be dependent on an option.
>> - Added 2 tests.
>>
>>
>> http://reviews.llvm.org/D11908
>>
>> Files:
>>  include/clang/Driver/Options.td
>>  include/clang/Frontend/CodeGenOptions.def
>>  lib/CodeGen/BackendUtil.cpp
>>  lib/Driver/Driver.cpp
>>  lib/Driver/Tools.cpp
>>  lib/Frontend/CompilerInvocation.cpp
>>  test/Driver/thinlto.c
>>  test/Misc/thinlto.c
>>
>> 
>
>> Index: test/Misc/thinlto.c
>> ===
>> --- /dev/null
>> +++ test/Misc/thinlto.c
>> @@ -0,0 +1,22 @@
>> +// RUN: %clang_cc1 -fthinlto -emit-llvm-bc < %s | llvm-bcanalyzer -dump | 
>> FileCheck %s
>> +// CHECK: > +// CHECK-NEXT: > +// CHECK-NEXT: > +// CHECK-NEXT: > +
>> +// RUN: %clang -fthinlto %s -o %t -fuse-ld=gold
>
> Why isn't this using -cc1?

I can try it again, but I believe -fuse-ld is not a -cc1 option.

>
>> +// RUN: llvm-bcanalyzer -dump %t.thinlto.bc | FileCheck %s 
>> --check-prefix=COMBINED
>> +// COMBINED: > +// COMBINED-NEXT: > +// COMBINED-NEXT: > +// COMBINED-NEXT: > +// COMBINED-NEXT: > +// COMBINED-NEXT: > +// COMBINED-NEXT: > +
>> +__attribute__((noinline)) void foo() {
>> +}
>> +
>> +int main() {
>> +  foo();
>> +}
>> Index: test/Driver/thinlto.c
>> ===
>> --- /dev/null
>> +++ test/Driver/thinlto.c
>> @@ -0,0 +1,11 @@
>> +// -fthinlto causes a switch to llvm-bc object files.
>> +// RUN: %clang -ccc-print-phases -c %s -fthinlto 2> %t.log
>> +// RUN: grep '2: compiler, {1}, ir' %t.log
>> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
>> +
>> +// RUN: %clang -ccc-print-phases %s -fthinlto 2> %t.log
>> +// RUN: grep '0: input, ".*thinlto.c", c' %t.log
>> +// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
>> +// RUN: grep '2: compiler, {1}, ir' %t.log
>> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
>> +// RUN: grep '4: linker, {3}, image' %t.log
>
> Usually we prefer FileCheck tests over grep (typically the grep tests
> are just old and haven't been converted yet).  Is there a particular
> reason you're using grep, or were you just copying an example?

This was cloned from test/Driver/lto.c. Let me see if I can rework
this with FileCheck.

>
>> Index: lib/Frontend/CompilerInvocation.cpp
>> ===
>> --- lib/Frontend/CompilerInvocation.cpp
>> +++ lib/Frontend/CompilerInvocation.cpp
>> @@ -518,6 +518,7 @@
>>Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
>>
>>Opts.PrepareForLTO = Args.hasArg(OPT_flto);
>> +  Opts.EmitThinLTOIndex = Args.hasArg(OPT_fthinlto);
>>
>>Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
>>
>> Index: lib/Driver/Tools.cpp
>> ===
>> --- lib/Driver/Tools.cpp
>> +++ lib/Driver/Tools.cpp
>> @@ -1664,6 +1664,9 @@
>>std::string CPU = getCPUName(Args, ToolChain.getTriple());
>>if (!CPU.empty())
>>  CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
>> +
>> +  if (Args.hasArg(options::OPT_fthinlto))
>> +CmdArgs.push_back("-plugin-opt=thinlto");
>>  }
>>
>>  /// This is a helper function for validating the optional refinement step
>> @@ -2818,6 +2821,8 @@
>>// preprocessing, precompiling or assembling.
>>Args.ClaimAllArgs(options::OPT_flto);
>>Args.ClaimAllArgs(options::OPT_fno_lto);
>> +  Args.ClaimAllArgs(options::OPT_fthinlto);
>> +  Args.ClaimAllArgs(options::OPT_fno_thinlto);
>>  }
>>
>>  static void appendUserToPath(SmallVectorImpl ) {
>> @@ -3236,6 +3241,8 @@
>> "Invalid action for clang tool.");
>>
>>  if (JA.getType() == types::TY_LTO_IR || JA.getType() == 
>> types::TY_LTO_BC) {
>> +  // Enables PrepareForLTO, which we want for -fthinlto as well.
>> +  // ThinLTO also uses the TY_LTO_* types.
>>CmdArgs.push_back("-flto");
>>  }
>>  if (JA.getType() == types::TY_Nothing) {
>> @@ -3268,6 +3275,10 @@
>>  // the use-list order, since serialization to bitcode is part of the 
>> flow.
>>  if (JA.getType() == types::TY_LLVM_BC)
>>CmdArgs.push_back("-emit-llvm-uselists");
>> +
>> +if (Args.hasArg(options::OPT_fthinlto)) {
>> +  CmdArgs.push_back("-fthinlto");
>> +}
>>}
>>
>>// We normally speed up the clang process a bit by skipping destructors at
>> Index: lib/Driver/Driver.cpp
>>

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-09-30 Thread Duncan P. N. Exon Smith via cfe-commits 

> On 2015-Sep-23, at 10:28, Teresa Johnson  wrote:
> 
> tejohnson updated this revision to Diff 35527.
> tejohnson added a comment.
> 
> Updated the patch for the new LLVM/gold patch 
> (http://reviews.llvm.org/D13107).
> 
> Two changes:
> 
> - I put back the original change to pass a new plugin option to gold. Since 
> the function index design/name has been generalized to not be 
> ThinLTO-specific, it makes sense to have the ThinLTO-related gold behavior 
> for modules with those sections to be dependent on an option.
> - Added 2 tests.
> 
> 
> http://reviews.llvm.org/D11908
> 
> Files:
>  include/clang/Driver/Options.td
>  include/clang/Frontend/CodeGenOptions.def
>  lib/CodeGen/BackendUtil.cpp
>  lib/Driver/Driver.cpp
>  lib/Driver/Tools.cpp
>  lib/Frontend/CompilerInvocation.cpp
>  test/Driver/thinlto.c
>  test/Misc/thinlto.c
> 
> 

> Index: test/Misc/thinlto.c
> ===
> --- /dev/null
> +++ test/Misc/thinlto.c
> @@ -0,0 +1,22 @@
> +// RUN: %clang_cc1 -fthinlto -emit-llvm-bc < %s | llvm-bcanalyzer -dump | 
> FileCheck %s
> +// CHECK:  +// CHECK-NEXT:  +// CHECK-NEXT:  +// CHECK-NEXT:  +
> +// RUN: %clang -fthinlto %s -o %t -fuse-ld=gold

Why isn't this using -cc1?

> +// RUN: llvm-bcanalyzer -dump %t.thinlto.bc | FileCheck %s 
> --check-prefix=COMBINED
> +// COMBINED:  +// COMBINED-NEXT:  +// COMBINED-NEXT:  +// COMBINED-NEXT:  +// COMBINED-NEXT:  +// COMBINED-NEXT:  +// COMBINED-NEXT:  +
> +__attribute__((noinline)) void foo() {
> +}
> +
> +int main() {
> +  foo();
> +}
> Index: test/Driver/thinlto.c
> ===
> --- /dev/null
> +++ test/Driver/thinlto.c
> @@ -0,0 +1,11 @@
> +// -fthinlto causes a switch to llvm-bc object files.
> +// RUN: %clang -ccc-print-phases -c %s -fthinlto 2> %t.log
> +// RUN: grep '2: compiler, {1}, ir' %t.log
> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
> +
> +// RUN: %clang -ccc-print-phases %s -fthinlto 2> %t.log
> +// RUN: grep '0: input, ".*thinlto.c", c' %t.log
> +// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
> +// RUN: grep '2: compiler, {1}, ir' %t.log
> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
> +// RUN: grep '4: linker, {3}, image' %t.log

Usually we prefer FileCheck tests over grep (typically the grep tests
are just old and haven't been converted yet).  Is there a particular
reason you're using grep, or were you just copying an example?

> Index: lib/Frontend/CompilerInvocation.cpp
> ===
> --- lib/Frontend/CompilerInvocation.cpp
> +++ lib/Frontend/CompilerInvocation.cpp
> @@ -518,6 +518,7 @@
>Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
>  
>Opts.PrepareForLTO = Args.hasArg(OPT_flto);
> +  Opts.EmitThinLTOIndex = Args.hasArg(OPT_fthinlto);
>  
>Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
>  
> Index: lib/Driver/Tools.cpp
> ===
> --- lib/Driver/Tools.cpp
> +++ lib/Driver/Tools.cpp
> @@ -1664,6 +1664,9 @@
>std::string CPU = getCPUName(Args, ToolChain.getTriple());
>if (!CPU.empty())
>  CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
> +
> +  if (Args.hasArg(options::OPT_fthinlto))
> +CmdArgs.push_back("-plugin-opt=thinlto");
>  }
>  
>  /// This is a helper function for validating the optional refinement step
> @@ -2818,6 +2821,8 @@
>// preprocessing, precompiling or assembling.
>Args.ClaimAllArgs(options::OPT_flto);
>Args.ClaimAllArgs(options::OPT_fno_lto);
> +  Args.ClaimAllArgs(options::OPT_fthinlto);
> +  Args.ClaimAllArgs(options::OPT_fno_thinlto);
>  }
>  
>  static void appendUserToPath(SmallVectorImpl ) {
> @@ -3236,6 +3241,8 @@
> "Invalid action for clang tool.");
>  
>  if (JA.getType() == types::TY_LTO_IR || JA.getType() == 
> types::TY_LTO_BC) {
> +  // Enables PrepareForLTO, which we want for -fthinlto as well.
> +  // ThinLTO also uses the TY_LTO_* types.
>CmdArgs.push_back("-flto");
>  }
>  if (JA.getType() == types::TY_Nothing) {
> @@ -3268,6 +3275,10 @@
>  // the use-list order, since serialization to bitcode is part of the 
> flow.
>  if (JA.getType() == types::TY_LLVM_BC)
>CmdArgs.push_back("-emit-llvm-uselists");
> +
> +if (Args.hasArg(options::OPT_fthinlto)) {
> +  CmdArgs.push_back("-fthinlto");
> +}
>}
>  
>// We normally speed up the clang process a bit by skipping destructors at
> Index: lib/Driver/Driver.cpp
> ===
> --- lib/Driver/Driver.cpp
> +++ lib/Driver/Driver.cpp
> @@ -1576,7 +1576,8 @@
>  }
>  
>  bool Driver::IsUsingLTO(const ArgList ) const {
> -  return Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false);
> +  return Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false) ||
> +

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-09-30 Thread Duncan P. N. Exon Smith via cfe-commits 

> On 2015-Sep-30, at 10:40, Teresa Johnson  wrote:
> 
> On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith
>  wrote:
>> 
>>> On 2015-Sep-23, at 10:28, Teresa Johnson  wrote:
>>> 
>>> tejohnson updated this revision to Diff 35527.
>>> tejohnson added a comment.
>>> 
>>> Updated the patch for the new LLVM/gold patch 
>>> (http://reviews.llvm.org/D13107).
>>> 
>>> Two changes:
>>> 
>>> - I put back the original change to pass a new plugin option to gold. Since 
>>> the function index design/name has been generalized to not be 
>>> ThinLTO-specific, it makes sense to have the ThinLTO-related gold behavior 
>>> for modules with those sections to be dependent on an option.
>>> - Added 2 tests.
>>> 
>>> 
>>> http://reviews.llvm.org/D11908
>>> 
>>> Files:
>>> include/clang/Driver/Options.td
>>> include/clang/Frontend/CodeGenOptions.def
>>> lib/CodeGen/BackendUtil.cpp
>>> lib/Driver/Driver.cpp
>>> lib/Driver/Tools.cpp
>>> lib/Frontend/CompilerInvocation.cpp
>>> test/Driver/thinlto.c
>>> test/Misc/thinlto.c
>>> 
>>> 
>> 
>>> Index: test/Misc/thinlto.c
>>> ===
>>> --- /dev/null
>>> +++ test/Misc/thinlto.c
>>> @@ -0,0 +1,22 @@
>>> +// RUN: %clang_cc1 -fthinlto -emit-llvm-bc < %s | llvm-bcanalyzer -dump | 
>>> FileCheck %s
>>> +// CHECK: >> +// CHECK-NEXT: >> +// CHECK-NEXT: >> +// CHECK-NEXT: >> +
>>> +// RUN: %clang -fthinlto %s -o %t -fuse-ld=gold
>> 
>> Why isn't this using -cc1?
> 
> I can try it again, but I believe -fuse-ld is not a -cc1 option.

Oh, right, of course.  -cc1 doesn't invoke the linker, the driver does.

In that case, it seems to me like you should:
1. have a driver test that uses -### to check that you're getting the
expected linker command-line (in test/Driver), and
2. somewhere (probably in test/tools/gold in LLVM?) confirm that gold
does the right thing with the thinlto plugin.



>>> +// RUN: llvm-bcanalyzer -dump %t.thinlto.bc | FileCheck %s 
>>> --check-prefix=COMBINED
>>> +// COMBINED: >> +// COMBINED-NEXT: >> +// COMBINED-NEXT: >> +// COMBINED-NEXT: >> +// COMBINED-NEXT: >> +// COMBINED-NEXT: >> +// COMBINED-NEXT: >> +
>>> +__attribute__((noinline)) void foo() {
>>> +}
>>> +
>>> +int main() {
>>> +  foo();
>>> +}
>>> Index: test/Driver/thinlto.c
>>> ===
>>> --- /dev/null
>>> +++ test/Driver/thinlto.c
>>> @@ -0,0 +1,11 @@
>>> +// -fthinlto causes a switch to llvm-bc object files.
>>> +// RUN: %clang -ccc-print-phases -c %s -fthinlto 2> %t.log
>>> +// RUN: grep '2: compiler, {1}, ir' %t.log
>>> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
>>> +
>>> +// RUN: %clang -ccc-print-phases %s -fthinlto 2> %t.log
>>> +// RUN: grep '0: input, ".*thinlto.c", c' %t.log
>>> +// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
>>> +// RUN: grep '2: compiler, {1}, ir' %t.log
>>> +// RUN: grep '3: backend, {2}, lto-bc' %t.log
>>> +// RUN: grep '4: linker, {3}, image' %t.log
>> 
>> Usually we prefer FileCheck tests over grep (typically the grep tests
>> are just old and haven't been converted yet).  Is there a particular
>> reason you're using grep, or were you just copying an example?
> 
> This was cloned from test/Driver/lto.c. Let me see if I can rework
> this with FileCheck.
> 
>> 
>>> Index: lib/Frontend/CompilerInvocation.cpp
>>> ===
>>> --- lib/Frontend/CompilerInvocation.cpp
>>> +++ lib/Frontend/CompilerInvocation.cpp
>>> @@ -518,6 +518,7 @@
>>>   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
>>> 
>>>   Opts.PrepareForLTO = Args.hasArg(OPT_flto);
>>> +  Opts.EmitThinLTOIndex = Args.hasArg(OPT_fthinlto);
>>> 
>>>   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
>>> 
>>> Index: lib/Driver/Tools.cpp
>>> ===
>>> --- lib/Driver/Tools.cpp
>>> +++ lib/Driver/Tools.cpp
>>> @@ -1664,6 +1664,9 @@
>>>   std::string CPU = getCPUName(Args, ToolChain.getTriple());
>>>   if (!CPU.empty())
>>> CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
>>> +
>>> +  if (Args.hasArg(options::OPT_fthinlto))
>>> +CmdArgs.push_back("-plugin-opt=thinlto");
>>> }
>>> 
>>> /// This is a helper function for validating the optional refinement step
>>> @@ -2818,6 +2821,8 @@
>>>   // preprocessing, precompiling or assembling.
>>>   Args.ClaimAllArgs(options::OPT_flto);
>>>   Args.ClaimAllArgs(options::OPT_fno_lto);
>>> +  Args.ClaimAllArgs(options::OPT_fthinlto);
>>> +  Args.ClaimAllArgs(options::OPT_fno_thinlto);
>>> }
>>> 
>>> static void appendUserToPath(SmallVectorImpl ) {
>>> @@ -3236,6 +3241,8 @@
>>>"Invalid action for clang tool.");
>>> 
>>> if (JA.getType() == types::TY_LTO_IR || JA.getType() == 
>>> types::TY_LTO_BC) {
>>> +  // Enables PrepareForLTO, which we want for -fthinlto as well.
>>> +  // ThinLTO also uses the TY_LTO_*

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-09-30 Thread Duncan P. N. Exon Smith via cfe-commits 
+echristo, +espindola, +pcc

> On 2015-Sep-30, at 12:39, Teresa Johnson  wrote:
> 
> On Wed, Sep 30, 2015 at 11:11 AM, Duncan P. N. Exon Smith
>  wrote:
>> 
>>> On 2015-Sep-30, at 10:40, Teresa Johnson  wrote:
>>> 
>>> On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith
>>>  wrote:
 
> On 2015-Sep-23, at 10:28, Teresa Johnson  wrote:
> 
> Index: include/clang/Driver/Options.td
> ===
> --- include/clang/Driver/Options.td
> +++ include/clang/Driver/Options.td
> @@ -686,6 +686,9 @@
> def flto_EQ : Joined<["-"], "flto=">, 
> Group;
> def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group;
> def fno_lto : Flag<["-"], "fno-lto">, Group;
> +def fthinlto : Flag<["-"], "fthinlto">, Flags<[CC1Option]>, 
> Group;
 
 I wonder whether this is the right way to add new variants of LTO.
 I.e., maybe this should be "-flto=thin"?  Do you happen to know how this
 would conflict with GCC options?  (I see we ignore "-flto="...)
>>> 
>>> I looked at GCC docs and sources. It does have a -flto= variant. From
>>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:
>>> -
>>> If you specify the optional n, the optimization and code generation
>>> done at link time is executed in parallel using n parallel jobs by
>>> utilizing an installed make program. The environment variable MAKE may
>>> be used to override the program used. The default value for n is 1.
>>> 
>>> You can also specify -flto=jobserver to use GNU make's job server mode
>>> to determine the number of parallel jobs. This is useful when the
>>> Makefile calling GCC is already executing in parallel. You must
>>> prepend a ‘+’ to the command recipe in the parent Makefile for this to
>>> work. This option likely only works if MAKE is GNU make.
>>> 
>>> 
>>> I would anticipate that we may want to support something like this for
>>> ThinLTO eventually to specify the number of parallel jobs for the
>>> ThinLTO backend processes. So it might be confusing to overload
>>> -flto=.
>> 
>> Hmm.  You're right that the GCC usage seems pretty different.
>> 
>> I guess you're envisioning -fthinlto=jobserver?
> 
> Or -fthinlto=n.
> 
>> I wonder if we could
>> do this as -flto=thin,jobserver or something similar?
> 
> I am ok with -flto=thin and then later extending to -flto=thin,n etc.
> 
> This simplifies the interaction with -fno-lto.
> 
> I think a -flto=thin followed by -flto should probably revert to
> normal LTO, WDYT?
> 
> Another thing to consider is to add -flto=full or something like that
> which is currently an alias for -flto. So we would have:
> 
> -flto= where type could be "full" or "thin"
> -flto means -flto=full
> -fno-lto disables all types of flto
> and last option of the above 3 wins.

This SGTM.  "monolithic" might be more descriptive than "full", or
maybe someone has a better name.

Eric/Rafael/Peter: any thoughts about driver options?

>> 
>> It's pretty hard to remove driver options, so I think it's important to
>> get the interface right.  I anticipate that we'll add more LTO variants
>> in the future, so we should take care that this scales reasonably.
>> 
>> (This may be a good discussion for cfe-dev, not sure.)
>> 
 E.g., as a user I'd expect -fno-lto to turn off whatever LTO was turned
 on.  And I might expect -flto to override -fthinlto, or vice versa.
>>> 
>>> Good point, I think the last one should win. Looks like right now
>>> -fthinlto is effectively always winning. I will fix that.
>>> 
>>> Not sure about -fno-lto behavior if we leave -fthinlto as a separate
>>> option. Let me know what you think based on the GCC usage of -flto=.
>> 
>> Right, if they're totally separate, then either behaviour for -fno-lto
>> is confusing.

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

Re: [PATCH] D11908: Clang support for -fthinlto.

2015-09-23 Thread Teresa Johnson via cfe-commits 
tejohnson updated this revision to Diff 35527.
tejohnson added a comment.

Updated the patch for the new LLVM/gold patch (http://reviews.llvm.org/D13107).

Two changes:

- I put back the original change to pass a new plugin option to gold. Since the 
function index design/name has been generalized to not be ThinLTO-specific, it 
makes sense to have the ThinLTO-related gold behavior for modules with those 
sections to be dependent on an option.
- Added 2 tests.


http://reviews.llvm.org/D11908

Files:
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  lib/CodeGen/BackendUtil.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/thinlto.c
  test/Misc/thinlto.c

Index: test/Misc/thinlto.c
===
--- /dev/null
+++ test/Misc/thinlto.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -fthinlto -emit-llvm-bc < %s | llvm-bcanalyzer -dump | FileCheck %s
+// CHECK:  %t.log
+// RUN: grep '2: compiler, {1}, ir' %t.log
+// RUN: grep '3: backend, {2}, lto-bc' %t.log
+
+// RUN: %clang -ccc-print-phases %s -fthinlto 2> %t.log
+// RUN: grep '0: input, ".*thinlto.c", c' %t.log
+// RUN: grep '1: preprocessor, {0}, cpp-output' %t.log
+// RUN: grep '2: compiler, {1}, ir' %t.log
+// RUN: grep '3: backend, {2}, lto-bc' %t.log
+// RUN: grep '4: linker, {3}, image' %t.log
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -518,6 +518,7 @@
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.PrepareForLTO = Args.hasArg(OPT_flto);
+  Opts.EmitThinLTOIndex = Args.hasArg(OPT_fthinlto);
 
   Opts.MSVolatile = Args.hasArg(OPT_fms_volatile);
 
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -1664,6 +1664,9 @@
   std::string CPU = getCPUName(Args, ToolChain.getTriple());
   if (!CPU.empty())
 CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=mcpu=") + CPU));
+
+  if (Args.hasArg(options::OPT_fthinlto))
+CmdArgs.push_back("-plugin-opt=thinlto");
 }
 
 /// This is a helper function for validating the optional refinement step
@@ -2818,6 +2821,8 @@
   // preprocessing, precompiling or assembling.
   Args.ClaimAllArgs(options::OPT_flto);
   Args.ClaimAllArgs(options::OPT_fno_lto);
+  Args.ClaimAllArgs(options::OPT_fthinlto);
+  Args.ClaimAllArgs(options::OPT_fno_thinlto);
 }
 
 static void appendUserToPath(SmallVectorImpl ) {
@@ -3236,6 +3241,8 @@
"Invalid action for clang tool.");
 
 if (JA.getType() == types::TY_LTO_IR || JA.getType() == types::TY_LTO_BC) {
+  // Enables PrepareForLTO, which we want for -fthinlto as well.
+  // ThinLTO also uses the TY_LTO_* types.
   CmdArgs.push_back("-flto");
 }
 if (JA.getType() == types::TY_Nothing) {
@@ -3268,6 +3275,10 @@
 // the use-list order, since serialization to bitcode is part of the flow.
 if (JA.getType() == types::TY_LLVM_BC)
   CmdArgs.push_back("-emit-llvm-uselists");
+
+if (Args.hasArg(options::OPT_fthinlto)) {
+  CmdArgs.push_back("-fthinlto");
+}
   }
 
   // We normally speed up the clang process a bit by skipping destructors at
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1576,7 +1576,8 @@
 }
 
 bool Driver::IsUsingLTO(const ArgList ) const {
-  return Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false);
+  return Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false) ||
+  Args.hasFlag(options::OPT_fthinlto, options::OPT_fno_thinlto, false);
 }
 
 void Driver::BuildJobs(Compilation ) const {
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -268,6 +268,7 @@
 return;
 
   unsigned OptLevel = CodeGenOpts.OptimizationLevel;
+
   CodeGenOptions::InliningMethod Inlining = CodeGenOpts.getInlining();
 
   // Handle disabling of LLVM optimization, where we want to preserve the
@@ -610,7 +611,8 @@
 
   case Backend_EmitBC:
 getPerModulePasses()->add(
-createBitcodeWriterPass(*OS, CodeGenOpts.EmitLLVMUseLists));
+createBitcodeWriterPass(*OS, CodeGenOpts.EmitLLVMUseLists,
+CodeGenOpts.EmitThinLTOIndex));
 break;
 
   case Backend_EmitLL:
Index: include/clang/Frontend/CodeGenOptions.def
===
--- include/clang/Frontend/CodeGenOptions.def
+++ include/clang/Frontend/CodeGenOptions.def
@@ -72,7 +72,9 @@
 CODEGENOPT(InstrumentForProfiling , 1, 0) ///< Set when -pg is enabled.
 CODEGENOPT(LessPreciseFPMAD  , 1, 0) ///< Enable less precise MAD instructions to