Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On Wed, May 12, 2021 at 11:10 AM Martin Liška wrote: > > May I please ping this Richi? OK. Thanks, Richard. > Thanks, > Martin > > On 4/22/21 4:30 PM, Martin Liška wrote: > > On 4/22/21 2:47 PM, Richard Biener wrote: > >> On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote: > >>> > >>> On 4/22/21 1:19 PM, Richard Biener wrote: > On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: > > > > On 4/22/21 10:04 AM, Richard Biener wrote: > >> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. > > > > That's doable and I've just done that in the attached patch. > > Two disadvantages: > > - one needs waiting for the warning after WPA > > - source change (>1 LTRANS) can trigger the warning > > > >> > 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). > > > > I managed printing the warning: > > > > lto-wrapper: warning: jobserver is not available: ‘MAKEFLAGS’ environment > > variable is unset > > > > lto-wrapper: note: see the ‘-flto’ option documentation for more information > > > > > > and > > > > lto-wrapper: warning: using serial compilation of 128 LTRANS jobs > > > > lto-wrapper: note: see the ‘-flto’ option documentation for more information > > > > > >> > > 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?) > > > > Done that. > > > > Thoughts? > > Martin > > > >> > >> 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) > >>> { > >>> -- > >>>
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
May I please ping this Richi? Thanks, Martin On 4/22/21 4:30 PM, Martin Liška wrote: On 4/22/21 2:47 PM, Richard Biener wrote: On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote: On 4/22/21 1:19 PM, Richard Biener wrote: On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: On 4/22/21 10:04 AM, Richard Biener wrote: On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. That's doable and I've just done that in the attached patch. Two disadvantages: - one needs waiting for the warning after WPA - source change (>1 LTRANS) can trigger the warning 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). I managed printing the warning: lto-wrapper: warning: jobserver is not available: ‘MAKEFLAGS’ environment variable is unset lto-wrapper: note: see the ‘-flto’ option documentation for more information and lto-wrapper: warning: using serial compilation of 128 LTRANS jobs lto-wrapper: note: see the ‘-flto’ option documentation for more information 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?) Done that. Thoughts? Martin 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
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On 4/22/21 2:47 PM, Richard Biener wrote: > On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote: >> >> On 4/22/21 1:19 PM, Richard Biener wrote: >>> On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: On 4/22/21 10:04 AM, Richard Biener wrote: > On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. That's doable and I've just done that in the attached patch. Two disadvantages: - one needs waiting for the warning after WPA - source change (>1 LTRANS) can trigger the warning > >>> 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). I managed printing the warning: lto-wrapper: warning: jobserver is not available: ‘MAKEFLAGS’ environment variable is unset lto-wrapper: note: see the ‘-flto’ option documentation for more information and lto-wrapper: warning: using serial compilation of 128 LTRANS jobs lto-wrapper: note: see the ‘-flto’ option documentation for more information > >>> >>> 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?) Done that. Thoughts? Martin > > 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 >> >> >From 7cd89e17c49c027027e2aed1722c0758331ac7ac Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Thu, 22 Apr 2021 16:27:19 +0200 Subject: [PATCH] Print warning diagnostics for -flto issues. gcc/ChangeLog: * lto-wrapper.c (print_lto_docs_link): New function. (run_gcc): Print warning about missing job server detection after we know NR of partitions. Do the same for -flto{,=1}. * opts.c (get_option_html_page): Support -flto option. --- gcc/lto-wrapper.c | 39 +-- gcc/opts.c| 6 +- 2 files changed, 42 insertions(+), 3 deletions(-) diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index 0b62
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On Thu, Apr 22, 2021 at 2:21 PM Martin Liška wrote: > > On 4/22/21 1:19 PM, Richard Biener wrote: > > On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: > >> > >> On 4/22/21 10:04 AM, Richard Biener wrote: > >>> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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 > > >> >
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On 4/22/21 1:19 PM, Richard Biener wrote: > On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: >> >> On 4/22/21 10:04 AM, Richard Biener wrote: >>> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. > > 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. > > 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? 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 >>
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote: > > On 4/22/21 10:04 AM, Richard Biener wrote: > > On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. IMHO we should eventually emit diagnostic like warning: could not find jobserver, compiling N jobs serially once N > 1 (or 2?). Likewise if people just use -flto and auto-detection finds nothing: 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. That is, teach users rather than second-guessing and eventually blowing things up. IMHO only the jobserver mode is safe to automatically use. 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 > >> >
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On 4/22/21 10:04 AM, Richard Biener wrote: > On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. 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 >> >From b81f5288fc81256e63d44e00793e2732eb2a2d88 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Thu, 22 Apr 2021 10:59:51 +0200 Subject: [PATCH] Document -flto=jobserver fallback. gcc/ChangeLog: * doc/invoke.texi: Document what happens when GCC can't detect make's job server with -flto=jobserver. --- gcc/doc/invoke.texi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index e98b0962b9f..1cfff4c14a9 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -12340,6 +12340,9 @@ Use @option{-flto=auto} to use GNU make's job server, if available, or otherwise fall back to autodetection of the number of CPU threads present in your system. +If you specify @option{-flto=jobserver} and make's job server can't be detected, +then well fall back to the number of CPU threads present in your system. + @item -flto-partition=@var{alg} @opindex flto-partition Specify the partitioning algorithm used by the link-time optimizer. -- 2.31.1
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On Wed, Apr 21, 2021 at 3:08 PM Martin Liška 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. 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 >
Re: [PATCH] LTO: fallback to -flto=N if -flto=jobserver does not work.
On 4/21/2021 5:50 AM, Martin Liška 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? 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. OK jeff