public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amylaar at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/49477] New: Should have user/debugger-oriented fine-tuning of optimizations available Date: Mon, 20 Jun 2011 17:51:00 -0000 [thread overview] Message-ID: <bug-49477-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2011-06-20 17:51 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-06-20 17:51 amylaar at gcc dot gnu.org [this message] 2011-06-21 9:50 ` [Bug rtl-optimization/49477] " rguenth at gcc dot gnu.org 2021-09-12 20:39 ` pinskia at gcc dot gnu.org 2021-09-13 7:42 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-49477-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).