From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17666 invoked by alias); 7 Mar 2013 08:48:10 -0000 Received: (qmail 16854 invoked by uid 55); 7 Mar 2013 08:47:37 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2 Date: Thu, 07 Mar 2013 08:48: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-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2013-03/txt/msg00568.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #29 from rguenther at suse dot de 2013-03-07 08:47:35 UTC --- On Thu, 7 Mar 2013, steven at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 > > --- Comment #25 from Steven Bosscher 2013-03-07 00:08:26 UTC --- > (In reply to comment #24) > > (In reply to comment #22) > > > 4.8.0 -O2 (terminated after 9 minutes waiting, LIM being the offender, I > > > suspect domwalk ...) >2.5GB > > > > > > applying domwalk fix ... > > > > It is LIM, for sure. I've been watching in GDB for a while at some > > back traces, and it's spent minutes already in this DOM walk: > > After this, it's spending even more time in refs_independent_p, doing > bitmap tests (ah! a test case for my splay tree bitmaps!). > > Is the refs_independent_p relation symmetric? It certainly looks that > way. If so, one way to halve the work done here is to build only half > the "independence" graph. Currently it builds a full square: > > if (mem_refs_may_alias_p (ref1->mem, ref2->mem, > &memory_accesses.ttae_cache)) > { > bitmap_set_bit (ref1->dep_ref, ref2->id); > bitmap_set_bit (ref2->dep_ref, ref1->id); > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, "dependent.\n"); > return false; > } > else > { > bitmap_set_bit (ref1->indep_ref, ref2->id); > bitmap_set_bit (ref2->indep_ref, ref1->id); > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, "independent.\n"); > return true; > } > > It's hard to say how much memory is wasted here (obstack_memory_used > is still broken and overflows), but it's probably x*100MB if not more. Yeah, one of my minor TLC patches. Most of the excessive memory usage for regular testcases can be fixed by doing LIM on all siblings of the loop tree independently, instead of keeping data on all loops in the function live at the same time (I've not finished _that_ TLC patch - and it won't help for insanely deep nests, of course)