From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6474A385843A; Fri, 10 Feb 2023 08:38:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6474A385843A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676018290; bh=OIkf6kPvPUM2L8KIh5jvKG18OKu8UiDCG9NARZWQaoI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bcSa8GIUk9PQfovtv7jDyH1q4TcFZShUUb9+biCnwxeG6pYaCr79HM9QU42sDyfi0 UE+/B9fgYUvZsJJfnkQ6Hf+bL2tg787wolDTlrzdTso8xdqcrVlbV+P5tSOSuXnKsG PqmUcsEHhA0aYp6rfUfB0Ljfb3q0Mex9pFr1m4WQ= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108696] querying relations is slow Date: Fri, 10 Feb 2023 08:38:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108696 --- Comment #4 from Richard Biener --- (In reply to Andrew Macleod from comment #2) > Created attachment 54437 [details] > possible patch >=20 > This patch should successfully short circuit unnecessary checks. untested= in > compiler.i >=20 > Where did you get a 17% time in DOM? when I run compiler.i I get > dominator optimization : 38.28 ( 2%)=20 > where most of the time is in > machine dep reorg :1447.64 ( 60%)=20 >=20 > I'll check this patch for correctness and to see if it generally makes any > time improvements that are measurable elsewhere. It helps the callgrind profile but doesn't show any effect on the -ftime-re= port or a perf profile. For the testcase the bitmap operations in ranger are definitely visible in a perf profile (with call traces), and with -O1 it's mostly DOM and jump-threading that perform any ranger ops when diagnostics = are disabled. That said, not allocating the self-relation bitmaps at query time is definitely good (not 100% sure if the patch achieves that).=