lkml.org 
[lkml]   [2020]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v7 02/17] kbuild: add support for Clang LTO
On Fri, Nov 20, 2020 at 05:46:44PM -0800, Sami Tolvanen wrote:
> Sure, this looks good to me, I'll use this in v8. The only minor
> concern I have is that ThinLTO cannot be set as the default LTO mode,
> but I assume anyone who selects LTO is also capable of deciding which
> mode is better for them.

It could be re-arranged similar to what you had before, but like:

config LTO
bool "..."
depends on HAS_LTO
help
...

choice
prompt "LTO mode" if LTO
default LTO_GCC if HAS_LTO_GCC
default LTO_CLANG_THIN if HAS_LTO_CLANG
default LTO_CLANG_FULL
help
...

config LTO_CLANG_THIN
...

config LTO_CLANG_FULL
endchoice

Then the LTO is top-level yes/no, but depends on detected capabilities,
and the mode is visible if LTO is chosen, etc.

I'm not really sure which is better...

> > +config LTO_CLANG_THIN
> > + bool "Clang ThinLTO (EXPERIMENTAL)"
> > + depends on ARCH_SUPPORTS_LTO_CLANG_THIN
> > + select LTO_CLANG
> > + help
> > + This option enables Clang's ThinLTO, which allows for parallel
> > + optimization and faster incremental compiles compared to the
> > + CONFIG_LTO_CLANG_FULL option. More information can be found
> > + from Clang's documentation:
> > +
> > + https://clang.llvm.org/docs/ThinLTO.html
> > +
> > + If unsure, say Y.
> > endchoice
>
> The two LTO_CLANG_* options need to depend on HAS_LTO_CLANG, of course.

Whoops, yes. Thanks for catching that. :)

--
Kees Cook

\
 
 \ /
  Last update: 2020-11-21 21:13    [W:0.054 / U:1.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site