From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE42A386EC33; Tue, 29 Sep 2020 07:09:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE42A386EC33 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs Date: Tue, 29 Sep 2020 07:09:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 8.5 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 07:09:11 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D64928 --- Comment #31 from Richard Biener --- (In reply to lucier from comment #30) > I'm coming back to this project. >=20 > I naively thought "Well, I don't need arc profiling, I'll just set > -ftest-coverage without -fprofile-arcs" but it appears that I can't do th= at, > the gcda files are generated by -fprofile-arcs. >=20 > It seems to me that test coverage could be implemented simply by > instrumenting each basic block in an algorithm that's linear in the number > of basic blocks. Is it possible to do this? >=20 > Brad I don't think the instrumentation itself is the problem - it's already doing better than one counter per block. It's simply that the large source runs into multiple non-linearities in core pieces of the compiler that cannot be turned off ...=