From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28067 invoked by alias); 20 Jan 2014 10:48:21 -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 28013 invoked by uid 48); 20 Jan 2014 10:48:17 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled Date: Mon, 20 Jan 2014 10: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-Version: 4.9.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 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: 2014-01/txt/msg02130.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479 --- Comment #4 from Jakub Jelinek --- I don't see why do you think nobody would try to look at t[x][y][z] in the debugger. Anyway, I think we can do two things here. Obviously we can't give up on cunrolling it because that would be a clear -fcompare-debug failure. But: 1) in loop unrolling, analyze the debug stmts we are about to unroll, and if some of the debug stmts refer to a decl no other debug stmt in the loop refers to (though would need to take into account DECL_DEBUG_EXPR overlaps) and the expression in the debug stmt uses only SSA_NAMEs from before the loop, constants and/or debug exprs from the loop that satisfy that recursively, just emit the those debug stmts in the first iteration only and not repeat those in all the other unrolled iterations 1a) alternatively to that, write some debug stmt optimization pass, that would detect the case of useless debug stmts (saying something lives in what it is known to live at from earlier debug stmts already) 2) have some debug stmt limits (--param controlled), above which we start dropping debug stmts or resetting them just once or something similar. Because it is possible that there are multiple debug stmts per the same decl in the loop and 1) or 1a) can't do anything. Perhaps have the normal debug stmts in first iteration of the unrolled loop (or a few of them, depending on how many there are), then when we give up just reset all the debug stmts in some iteration and after that iteration and before last iteration don't emit debug stmts at all, then finally in the last iteration emit debug stmts again. Testcase for 2) is e.g. -O2 -g: int a, b, c, d, e; int main () { for (a = 0; a < 16; a++) for (b = 0; b < 16; b++) for (c = 0; c < 16; c++) for (d = 0; d < 16; d++) for (e = 0; e < 16; e++) { int f; #define F10 f = 0; f = 1; f = 2; f = 3; f = 4; f = 5; f = 6; f = 7; f = 8; f = 9; #define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10 F100 } return 0; } Another testcase, with no unrolling at all, that shows that it is easy to get thousands of debug stmts: int a, b, c, d, e, f; int main () { #define F1 {{f, f, f, f, f, f, f, f, f}, {f, f, f, f, f, f, f, f, f}}, #define F10 F1 F1 F1 F1 F1 F1 F1 F1 F1 F1 #define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10 #define F1000 F100 F100 F100 F100 F100 F100 F100 F100 F100 F100 int t[1000][2][9] = { F1000 }; return 0; } not sure where if at all to put any --param limits here though, after all, you get for this in the initializers as huge spaghetti code and only later on that is transformed into no actual code, just DEBUG stmt spaghetti. Though, supposedly this last example is already related to the PR59659 patch (which I've done for C++ only so far).