From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17826 invoked by alias); 6 Mar 2015 12:47:34 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17764 invoked by uid 48); 6 Mar 2015 12:47:31 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/64928] [4.8/4.9/5 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs Date: Fri, 06 Mar 2015 12:47:00 -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-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg00702.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #16 from Richard Biener --- Created attachment 34974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34974&action=edit Patch to limit coalescing amount The committed patch improves peak memory usage from 7.6GB to 5.8GB for the small testcase. The attached patch reduces memory usage from SSA coalescing further (to ~300MB) by simply doing less coalescing. Unfortunately the generated RTL puts a bigger load on CSE/DF and thus we need 7.6GB again (eventually one can find an optimal --param max-out-of-ssa-coalesce-names, but that's probably highly testcase specific). In theory you can iterate on coalescing piecewise as well, but the overhead for doing this might be too big (basically up to computing live/conflict for each coalesce pair separately, taking into account previous coalesces).