From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 7B0253858C53; Tue, 28 Mar 2023 08:30:55 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7B0253858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679992255;
	bh=6YCuB2KyS7pV5hJC86DZLQwVKbPNiafduOwHINlrn5A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=f0n8LRDEFvAoulFZFV2R+6AW2IGWxszCwadztY9uQ/6SA2dG8qkyii8Zs/+EXtnLO
	 +plR5o6K6z7JEYS/zVtFP+XYfovdExCrxQvSNNugO2HXIy6jIw/+LSAT8FYUpBXOlq
	 pUgeBczZfcRT71v9UYyIilZa3yU0neHRVNyTs/G0=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/84402] [meta] GCC build system: parallelism
 bottleneck
Date: Tue, 28 Mar 2023 08:30:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: build, meta-bug
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-84402-4-0yYtwA4jGW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-84402-4@http.gcc.gnu.org/bugzilla/>
References: <bug-84402-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Li=C5=A1ka from comment #59)
> (In reply to Andrew Carlotti from comment #58)
> > Since November 2021, there's been a significant regression in the compi=
le
> > time for gimple-match.cc during a bootstrap build (+100% in Stage 2, +7=
3% in
> > Stage 3), with this regression accounting for over 20% of the current t=
otal
> > bootstrap time on some aarch64 machines.
>=20
> Thank for the interesting numbers! Yeah, it's very unfortunate :/
>=20
> >=20
> > Most of the change in compile time is due to the following 6 commits (of
> > which one is a performance improvement, and one only regressed the Stag=
e 2
> > build):
> >=20
> > 7df89377a7ae3906255e38a79be8e5d962c3a0df 24th November 2021
> > Enhance optimize_atomic_bit_test_and to handle truncation. (Hongtao Liu)
> > Stage 2: +27%
> > Stage 3: +33%
>=20
> This one is btw. a known issue PR108129.

But the revision only sligthly changes the patterns so I'm very curious
how it arrived at 30% slowdown.

Note these (match ..) patterns that are not used from inside match.pd itself
(and do not use other (match ..)) would be perfect candidates to emit
to separate files.  Either by explicit syntax or magically where the former
would be easier to cater for in the Makefile.

The "trivial" improvement of course would be to special-case
iterator uses als for (match ...) like we do for (simplify ...) where
we can delay substitution.=