From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129920 invoked by alias); 24 Feb 2015 15:41:39 -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 129835 invoked by uid 55); 24 Feb 2015 15:41:35 -0000 From: "aldyh at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g Date: Tue, 24 Feb 2015 16:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: aldyh at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg02671.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #21 from Aldy Hernandez --- On 02/24/2015 12:39 AM, rguenther at suse dot de wrote: > But yes, we have multiple such assignments to 'this' at the (possible > assembler) location of a single statement which of course doesn't help. > > Thus we should DCE the debug stmt sequences between real stmts like > >> D.166591 ={v} {CLOBBER}; >> # DEBUG this => &D.166589 >> # DEBUG D#20 => &D.166589.D.71066 >> # DEBUG this => D#20 >> # DEBUG D#19 => &D#20->D.67748 >> # DEBUG this => D#19 >> _1479 = &MEM[(struct Row *)&D.166589].D.66121; > > to the following at least ("DSE" actually, based on the actual > name of the LHS a debugger might use to refer to the variable) Let me see if I understood this correctly. We need a DSE/DCE pass right before var-tracking that would eliminate the redundant `this' statements right before a non debug statement. So, for something like this: # DEBUG this => &cs # DEBUG D#61 => &cs.D.73561 # DEBUG this => D#61 # DEBUG topol => 0 # DEBUG D#60 => &D#61->D.71953 # DEBUG this => D#60 # DEBUG D#59 => &D#60->rows # DEBUG this => D#59 # DEBUG D#58 => &D#59->D.66859 # DEBUG this => D#58 # DEBUG D#57 => &D#58->_M_impl # DEBUG this => D#57 # DEBUG this => D#57 # DEBUG this => D#57 MEM[(struct _Vector_impl *)&cs]._M_start = 0B; : # DEBUG this => &D.166575 # DEBUG D#21 => &D.166575.D.73843 # DEBUG this => D#21 # DEBUG D#19 => &D#21->D.67748 # DEBUG this => D#19 _1448 = &MEM[(struct Row *)&D.166575].D.66121; Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448); ...we would delete all the "DEBUG this" in the first batch with the exception of the last one (DEBUG this => D#57). All the intervening "DEBUG D#[0-9][0-9]" statements would remain. For the second batch, we would also delete all the "DEBUG this" statements except the last one (DEBUG this => D#19)? Is this what you have in mind? > >> D.166591 ={v} {CLOBBER}; >> # DEBUG D#20 => &D.166589.D.71066 >> # DEBUG D#19 => &D#20->D.67748 >> # DEBUG this => D#19 >> _1479 = &MEM[(struct Row *)&D.166589].D.66121; > > As to "between stmts" that is because after each 'stepi' in the > debugger you reach a new state computed by var-tracking. Intermediate > state-transitions are not interesting as long as you preserve the > "last" state before the next instruction. > > Thus in reality you'd want to perform this DCE/DSE right before > var-tracking (or during the var-tracking insn scan phase) > >> Also, it may not be the DEBUG statements at fault, but the inefficiency >> of the testcase itself (creating all these objects), in which case, >> perhaps we could notice this behavior at var-tracking time, and bail? >> Though this sounds like a kludge. > > Of course the issue is very large and repetitive functions. Thus > another idea is to simply split up such functions. If just by > making var-tracking work on SESE (or SEME) regions and dealing > with the boundaries conservatively. > > Eventually this can be "hacked" by fake splitting/restoring the > CFG around vt_initialize/vt_find_locations/vt_finalize. Maybe > easier than to make them work on a CFG region. The DCE/DSE pass sounds more straightforward IMO, but I just don't want to deal with data flow equations ;-).