[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 26 Aug 2020, matz at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #11 from Michael Matz <matz at gcc dot gnu.org> ---
> (In reply to Jan Hubicka from comment #10)
> > > We could also punt: when enable-link-mutex we could artificially up the job
> > > number for make to account for the waiting link steps.  I.e. when normally -jN
> > > was given, the link step could be done under -j(N + nr-language - 1).  That
> > > would lead to the
> > > nr-of-languages-1 job server tokens taken up by the sleeping link steps to be
> > > accounted for, and hence the (single running) link step still be able to use N
> > > threads/processes in parallel.
> > 
> > I do not think it is easy to do with current make jobserver.  The
> > toplevel jobserver opens the pipi with -jN many tokens and all other
> > makes connect to it.  It does not provide interface to return a token
> > and re-take it unless we implement it of course.
> 
> Sure, but that's not the only way the above punting could be done.  The
> parallel
> phase that currently communicates with the jobserver essentially tries to get N
> tokens.  It could be changed to assume that there are implicitely
> nr-of-languages-1 more tokens available.  I.e. the number of threads/processes
> would always be enlarged by nr-of-languages-1, even without any tokens from the
> jobserver.

I wonder whether the link-mutex is better be implemented with
a set of artificial dependences.  If we want to serialize
building cc1, cc1plus, etc. then just have

cc1: cc1plus
cc1plus: ...
...

and only conditionally enable those somehow.  But IIRC nowadays
that "waiting" also prints those progress markers ...