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: * https://inbox.sourceware.org/gcc-patches/41109217-1bf5-b112-e783-8040196fd410@suse.cz/ * https://gcc.gnu.org/pipermail/gcc/2021-May/236030.html 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): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e commit bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-28 23:27:06 +0000 Commit: Sam James <sam@gentoo.org> 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). Bug: https://gcc.gnu.org/PR111619 Bug: https://bugs.gentoo.org/914881 Closes: https://bugs.gentoo.org/477548 Closes: https://bugs.gentoo.org/831423 Closes: https://bugs.gentoo.org/840392 Apologies-to: Matt Turner <mattst88@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> 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 > BOOT_CFLAGS). 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.
