On Thu, Apr 22, 2021 at 2:21 PM Martin Liška <mli...@suse.cz> wrote:
>
> On 4/22/21 1:19 PM, Richard Biener wrote:
> > On Thu, Apr 22, 2021 at 11:02 AM Martin Liška <mli...@suse.cz> wrote:
> >>
> >> On 4/22/21 10:04 AM, Richard Biener wrote:
> >>> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška <mli...@suse.cz> wrote:
> >>>>
> >>>> When -flto=jobserver is used and we cannot detect job server, then we can
> >>>> still fallbackto -flto=N mode.
> >>>>
> >>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>>>
> >>>> Ready to be installed?
> >>>
> >>> I think this behavior needs to be documented - it falls back to a less
> >>> conservative (possibly system overloading) mode - which IMHO is
> >>> non-obvious and IMHO we shouldn't do.
> >>
> >> Sure, I'm sending corresponding patch. Note that it's quite common mistake
> >> that '+' is missing in Makefile rule. That was motivation for my change.
> >
> > Sure, but that change won't get this fixed.
>
> It will as linker command line will contain (-flto=jobserver) and LTO will
> fallback to -flto=N.
>
> > IMHO we should eventually
> > emit diagnostic like
> >
> > warning: could not find jobserver, compiling N jobs serially
> >
> > once N > 1 (or 2?).
>
> We do that now (for all N):
> lto-wrapper: warning: jobserver is not available: ‘MAKEFLAGS’ environment
> variable is unset
>
>
> > Likewise if people just use -flto and auto-detection
> > finds nothing:
>
> -flto != -flto=auto
>
> Yes, -flto is a serial linking and we can emit a warning.
I'd avoid warning if there's just a single ltrans unit.
> > warning: using serial compilation of N LTRANS jobs
> > note: refer to http://.... for how to use parallel compile
> >
> > using the URL diagnostics to point to -flto=... documentation.
>
> What about making that a proper warning (-Wlto)? We have diagnostics
> infrastructure
> that prints URL links.
Note that drivers like lto-wrapper do not have fully initialized diagnostic
machinery and use a "different" set of overloads (likewise gen* programs).
> >
> > That is, teach users rather than second-guessing and eventually
> > blowing things up. IMHO only the jobserver mode is safe to
> > automatically use.
>
> Well, -flto=auto is also fine and document. I think there is no possibility
> auto CPU deduction can fail. So -flto=jobserver (with missing make job server)
> and -flto (equal to -flto=1) worth emitting a warning.
>
> What do you think?
Yes, that sounds reasonable. I suspect that people might want to see
-flto default to -flto=auto but then I don't think that's good because there's
no system wide job scheduler limiting things (systemd-jobserver anyone?)
Richard.
> Martin
>
> >
> > Richard.
> >
> >> Martin
> >>
> >>>
> >>> Richard.
> >>>
> >>>> Thanks,
> >>>> Martin
> >>>>
> >>>> gcc/ChangeLog:
> >>>>
> >>>> * lto-wrapper.c (run_gcc): When -flto=jobserver is used, but the
> >>>> makeserver cannot be detected, then use -flto=N fallback.
> >>>> ---
> >>>> gcc/lto-wrapper.c | 3 ++-
> >>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
> >>>> index 03a5922f8ea..0b626d7c811 100644
> >>>> --- a/gcc/lto-wrapper.c
> >>>> +++ b/gcc/lto-wrapper.c
> >>>> @@ -1585,8 +1585,9 @@ run_gcc (unsigned argc, char *argv[])
> >>>> if (jobserver && jobserver_error != NULL)
> >>>> {
> >>>> warning (0, jobserver_error);
> >>>> - parallel = 0;
> >>>> + /* Fall back to auto parallelism. */
> >>>> jobserver = 0;
> >>>> + auto_parallel = 1;
> >>>> }
> >>>> else if (!jobserver && jobserver_error == NULL)
> >>>> {
> >>>> --
> >>>> 2.31.1
> >>>>
> >>
>
