On Sun, Sep 06, 2020 at 05:17:32AM +0900, Masahiro Yamada wrote: > On Fri, Sep 4, 2020 at 5:31 AM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > > > This change adds build system support for Clang's Link Time > > Optimization (LTO). With -flto, instead of ELF object files, Clang > > produces LLVM bitcode, which is compiled into native code at link > > time, allowing the final binary to be optimized globally. For more > > details, see: > > > > https://llvm.org/docs/LinkTimeOptimization.html > > > > The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, > > which defaults to LTO being disabled. To use LTO, the architecture > > must select ARCH_SUPPORTS_LTO_CLANG and support: > > > > - compiling with Clang, > > - compiling inline assembly with Clang's integrated assembler, > > - and linking with LLD. > > > > While using full LTO results in the best runtime performance, the > > compilation is not scalable in time or memory. CONFIG_THINLTO > > enables ThinLTO, which allows parallel optimization and faster > > incremental builds. ThinLTO is used by default if the architecture > > also selects ARCH_SUPPORTS_THINLTO: > > > > https://clang.llvm.org/docs/ThinLTO.html > > > > To enable LTO, LLVM tools must be used to handle bitcode files. The > > easiest way is to pass the LLVM=1 option to make: > > > > $ make LLVM=1 defconfig > > $ scripts/config -e LTO_CLANG > > $ make LLVM=1 > > > > Alternatively, at least the following LLVM tools must be used: > > > > CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm > > > > To prepare for LTO support with other compilers, common parts are > > gated behind the CONFIG_LTO option, and LTO can be disabled for > > specific files by filtering out CC_FLAGS_LTO. > > > > Note that support for DYNAMIC_FTRACE and MODVERSIONS are added in > > follow-up patches. > > > > Signed-off-by: Sami Tolvanen <samitolvanen@xxxxxxxxxx> > > --- > > Makefile | 18 +++++++- > > arch/Kconfig | 68 +++++++++++++++++++++++++++++++ > > include/asm-generic/vmlinux.lds.h | 11 +++-- > > scripts/Makefile.build | 9 +++- > > scripts/Makefile.modfinal | 9 +++- > > scripts/Makefile.modpost | 24 ++++++++++- > > scripts/link-vmlinux.sh | 32 +++++++++++---- > > 7 files changed, 154 insertions(+), 17 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index a9dae26c93b5..dd49eaea7c25 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -909,6 +909,22 @@ KBUILD_CFLAGS += $(CC_FLAGS_SCS) > > export CC_FLAGS_SCS > > endif > > > > +ifdef CONFIG_LTO_CLANG > > +ifdef CONFIG_THINLTO > > +CC_FLAGS_LTO_CLANG := -flto=thin -fsplit-lto-unit > > +KBUILD_LDFLAGS += --thinlto-cache-dir=.thinlto-cache > > +else > > +CC_FLAGS_LTO_CLANG := -flto > > +endif > > +CC_FLAGS_LTO_CLANG += -fvisibility=default > > +endif > > + > > +ifdef CONFIG_LTO > > +CC_FLAGS_LTO := $(CC_FLAGS_LTO_CLANG) > > > $(CC_FLAGS_LTO_CLANG) is not used elsewhere. > > Why didn't you add the flags to CC_FLAGS_LTO > directly? > > Will it be useful if LTO_GCC is supported ? The idea was to allow compiler-specific LTO flags to be filtered out separately if needed, but you're right, this is not really necessary right now. I'll drop CC_FLAGS_LTO_CLANG in v3. Sami