On Wed, Sep 30, 2015 at 2:33 PM, Duncan P. N. Exon Smith <dexonsm...@apple.com> wrote: > +echristo, +espindola, +pcc > >> On 2015-Sep-30, at 12:39, Teresa Johnson <tejohn...@google.com> wrote: >> >> On Wed, Sep 30, 2015 at 11:11 AM, Duncan P. N. Exon Smith >> <dexonsm...@apple.com> wrote: >>> >>>> On 2015-Sep-30, at 10:40, Teresa Johnson <tejohn...@google.com> wrote: >>>> >>>> On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith >>>> <dexonsm...@apple.com> wrote: >>>>> >>>>>> On 2015-Sep-23, at 10:28, Teresa Johnson <tejohn...@google.com> 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<clang_ignored_gcc_optimization_f_Group>; >>>>>> def flto : Flag<["-"], "flto">, Flags<[CC1Option]>, Group<f_Group>; >>>>>> def fno_lto : Flag<["-"], "fno-lto">, Group<f_Group>; >>>>>> +def fthinlto : Flag<["-"], "fthinlto">, Flags<[CC1Option]>, >>>>>> Group<f_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=<type> 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
