[build2] LTO and parallelization with build2

[Matthew Krupcale]

On Fri, Aug 7, 2020 at 10:28 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
>
> I am not sure we want to mess with lto-partitions, feels like it can
> get GCC-version-dependent.

Yeah, that may make things unnecessarily complicated.

> Also, I would be weary of rewriting -flto=n;
> we generally assume the user knows what they are doing (and if not,
> they will appreciate an opportunity to learn ;-)).

Okay, should simplify the logic slightly as well.

> 2. It's GCC of sufficient version. (I wonder what's the story with
>    Clang here?)

GCC 10 should be the first to support -flto=auto[1]. I also looked
into the Clang situation, and it looks like it only allows control of
the number of threads/jobs when -flto=thin is used[2-4]. This is
controlled with -flto-jobs=N since version 4 I think[5].

> As for finding the option itself, we have the find_option_prefix()
> utility function that does almost what we need (we need the
> position, not the pointer to the option value). Maybe we can add
> find_option_prefix_position() or some such?

I wonder if instead of adding the _position variations, it might make
sense to change the API of the existing functions to work more like
e.g. std::find{,_if}. This would allow you to use the same function
for either examining the value found (i.e. *it) or working with the
position (i.e. it). Although, I don't know if you could adapt the
functions which take a const lookup& to this API.

[1] https://gcc.gnu.org/gcc-10/changes.html
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-flto-jobs
[3] https://clang.llvm.org/docs/ThinLTO.html
[4] http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html
[5] https://github.com/llvm/llvm-project/commit/12286d22b7964fa69e44c9d8ca36cc85d4cf5225