sys-devel/gcc: Default to -O1 for STAGE1_CFLAGS
Saves a bunch of time and gives the same ultimate result.
gcc-4.8.1 compile went to 13:19 from 15:22 on my fast Ivy Bridge system (13% speed up). Slower systems (think alpha, mips) see much larger benefits.
STAGE1_CFLAGS isn't set when bootstrapping, so it's whatever upstream uses. I worked towards that on purpose since before it was a source of bugs that upstream had no interest in fixing.
I was messing around in the build machinery again and as far as I can see we're already building stage 1 gcc with STAGE1_CFLAGS empty, ie. -O0, on native builds (we set it to an empty string because otherwise gcc sets it to BOOT_CFLAGS). gcc itself is built with STAGE1_CFLAGS, and then libraries built by it in stage 1 (libgcc, libgomp, libstdc++-v3, etc.) use either CFLAGS or BOOT_CFLAGS, so I'm not sure how you're seeing a speed up. Please reopen if I've missed something. I'm looking at 4.9.0 here but I checked build logs as far back as 4.6.
Times have changed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111619 made me revisit this.
It also turns out the GCC developers often use STAGE1_CFLAGS to speed things up:
Previous times for gcc 13:
2023-07-30T19:51:46 >>> sys-devel/gcc-13.2.1_p20230729: 1:21:36
2023-08-01T16:16:22 >>> sys-devel/gcc-13.2.1_p20230729: 1:45:12
2023-08-06T00:12:55 >>> sys-devel/gcc-13.2.1_p20230805: 1:22:01
2023-08-13T02:13:36 >>> sys-devel/gcc-13.2.1_p20230812: 1:37:06
2023-08-20T07:07:07 >>> sys-devel/gcc-13.2.1_p20230819: 1:43:02
2023-08-27T00:27:00 >>> sys-devel/gcc-13.2.1_p20230826: 1:42:41
2023-09-01T04:49:42 >>> sys-devel/gcc-13.2.1_p20230826: 1:31:57
2023-09-02T00:54:34 >>> sys-devel/gcc-13.2.1_p20230826: 1:36:01
2023-09-03T05:34:29 >>> sys-devel/gcc-13.2.1_p20230902: 1:37:19
2023-09-10T08:00:56 >>> sys-devel/gcc-13.2.1_p20230909: 1:37:42
2023-09-17T01:24:05 >>> sys-devel/gcc-13.2.1_p20230916: 1:34:30
2023-09-24T02:34:47 >>> sys-devel/gcc-13.2.1_p20230923: 1:40:26
2023-09-28T07:30:17 >>> sys-devel/gcc-13.2.1_p20230923: 1:34:10
2023-09-28T11:12:54 >>> sys-devel/gcc-13.2.1_p20230923: 1:11:17 <-- with the change
That seems like a consistent improvement of, in the most consrvative intepretation, 10 minutes, and possibly as much as 25-30 minutes.
(In reply to Sam James from comment #3)
(all times w/ USE="lto pgo")
For gcc 12 w/ USE="-lto -pgo":
2023-07-08T04:44:25 >>> sys-devel/gcc-12.3.1_p20230707: 47′06″
2023-07-15T10:24:27 >>> sys-devel/gcc-12.3.1_p20230714: 52′59″
2023-07-22T02:03:14 >>> sys-devel/gcc-12.3.1_p20230721: 44′05″
2023-07-30T11:19:23 >>> sys-devel/gcc-12.3.1_p20230728: 38′57″
2023-08-01T15:53:00 >>> sys-devel/gcc-12.3.1_p20230728: 53′05″
2023-08-05T02:21:16 >>> sys-devel/gcc-12.3.1_p20230804: 34′04″
2023-08-12T05:08:44 >>> sys-devel/gcc-12.3.1_p20230811: 45′00″
2023-08-19T05:51:16 >>> sys-devel/gcc-12.3.1_p20230818: 39′07″
2023-08-26T00:25:48 >>> sys-devel/gcc-12.3.1_p20230825: 42′37″
2023-09-02T00:25:47 >>> sys-devel/gcc-12.3.1_p20230825: 50′56″
2023-09-02T13:01:14 >>> sys-devel/gcc-12.3.1_p20230901: 40′42″
2023-09-09T03:05:45 >>> sys-devel/gcc-12.3.1_p20230908: 43′13″
2023-09-16T05:14:22 >>> sys-devel/gcc-12.3.1_p20230915: 43′11″
2023-09-23T00:46:41 >>> sys-devel/gcc-12.3.1_p20230922: 47′33″
2023-09-28T13:25:57 >>> sys-devel/gcc-12.3.1_p20230922: 34′00″
so a clear improvement again.
The bug has been closed via the following commit(s):
Author: Sam James <firstname.lastname@example.org>
AuthorDate: 2023-09-28 23:27:06 +0000
Commit: Sam James <email@example.com>
CommitDate: 2023-09-30 09:38:40 +0000
toolchain.eclass: rework bootstrapping logic
* Build stage1 compiler with user's CFLAGS. This consistently ends up
saving at least 15 minutes for me on a fast amd64 machine and should save
more on slower machines and architectures.
There's only any risk here if the host compiler is ancient/very buggy and
even then, you get a failed bootstrap later on. The GCC developers, per the
linked bug, end up using STAGE1_CFLAGS="-O2" anyway to speed up the process
so it's not like this is untested at all.
mattst88 actually brought this up.. 10 years ago (bug #477548). Let's try
make that right now.
* Respect LDFLAGS for target libraries for native builds. Not touching this
for cross builds, at least for now, as it's a bit more delicate.
(Unfortunately, we have to put a hack in here for now until we can fix
multilib.eclass - see bug #914881).
Apologies-to: Matt Turner <firstname.lastname@example.org>
Signed-off-by: Sam James <email@example.com>
eclass/toolchain.eclass | 52 +++++++++++++++++++++++++++++++++----------------
1 file changed, 35 insertions(+), 17 deletions(-)
(In reply to Ryan Hill (RETIRED) from comment #2)
> I was messing around in the build machinery again and as far as I can see
> we're already building stage 1 gcc with STAGE1_CFLAGS empty, ie. -O0, on
> native builds (we set it to an empty string because otherwise gcc sets it to
Just to be clear: this was precisely the problem (building with no optimisation).
I didn't quite get what Ryan meant here, until Matt and I discussed it on IRC, and concluded the consensus must have been "well, it's slower to build with the optimisations" and hence it'd be going -O2 -> -O1 or something rather than -O0 -> -O1.