From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10134 invoked by alias); 20 Jun 2011 17:51:35 -0000 Received: (qmail 10118 invoked by uid 22791); 20 Jun 2011 17:51:33 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 17:51:19 +0000 From: "amylaar at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/49477] New: Should have user/debugger-oriented fine-tuning of optimizations available X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: amylaar at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 20 Jun 2011 17:51:00 -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 X-SW-Source: 2011-06/txt/msg01799.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477 Summary: Should have user/debugger-oriented fine-tuning of optimizations available Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: amylaar@gcc.gnu.org [N.B. This concerns tree-optimization issues too, albeit scheduling/delay slot scheduling and reload optimizations are probably the worst offenders.] As observed at the GCC gathering, we lack a way for users to specify what optimizations to suppress in terms of what the optimizations impact on debugging experience would be. When users want to debug a program, the often don't care what the transformations or algorithms are that make debugging hell, they just want them turned off, while leaving innocuous optimization active so that program size/runtime doesn't become too much of an issue. We have -O0 and -O1 traditionally associated with a general 'level' of debugging experience, but -O0 has been broken with the advent of always-on optimizations like tree constant folding by the over-generalization that people tune down optimization only for the sake of compiler speed, and -O1 has a rather fuzzy meaning on debugging at best. E.g. scheduling, delay slot scheduling, and code reordering done by reload to reduce register lifetimes cause fine-grained code reordering that makes stepping through the code very confusing, and also if you set a breakpoint and debug info for a variable is available, that does not mean that the state of the variable as any relation to the value it should have according to the source line you set the breakpoint on. Thus, it would be good if we had an option to turn off all fine grained code reordering, whatever phase or algorithm does it. And also an option to turn off all code reordering altogether. For cases where exactly hitting hardware watch points are important, an option to prevent any kind of store sinking or otherwise postponing writes to user variables and/or allocated memory would be useful. This might be differentiated on type of variable, e.g. global versus local. For local variables, strength reduction of a loop counter arguably prevents storing the loop index altogether, so should also be inhibited or watered down so that the stores occur. If the required debugging feature is that people want to be able to observe values of variables truthfully according to the source code, stores to memory location are not that important *provided that* we have debug info available to compute the value of each variable. And there should also be an option to just turn of all optimization that have any impact on program behaviour with regards to stepping, breakpoints, watchpoints, and observable/observed values, even if that makes the compilation take longer than our current optimizing -O0 because of code bloat. So we would have three levels of selecting optimizations: - -On / -Os, selecting optimizations depending on compilation effort / run time trade off and code size considerations. - Overriding this, options turning off or watering down optimizations that impact particular or any aspects of debugging. - Overriding this, options to turn specific optimizations on or off, for people who know what they are doing with regards to this micromanagement.