[Bug rtl-optimization/49477] New: Should have user/debugger-oriented fine-tuning of optimizations available

[Bug rtl-optimization/49477] New: Should have user/debugger-oriented fine-tuning of optimizations available

[amylaar at gcc dot gnu.org]

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.

[Bug rtl-optimization/49477] Should have user/debugger-oriented fine-tuning of optimizations available

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.21 09:48:59
                 CC|                            |hubicka at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-21 09:48:59 UTC ---
Confirmed.

We should

 1) disable unneeded optimization at -O0 (we do a lot of folding)
 2) look at -O1 (it's basically "untuned" for the last years), make
    it the intended "reasonable optimization with good compile-time
    and debugging experience" again.

For -O1 my idea was to simply _only_ do early optimizations, thus drop
any IPA optimizations from it and not execute pass_all_optimizations.
In addition to that from early optimizations disable
pass_sra_early, pass_early_ipa_sra and pass_convert_switch.  Eventually
insert a DSE pass early (not really sure).

It'll of course change fundamentally what code we emit for -O1, but at
least we have strong CSE/DCE passes and early inlining that is able
to remove C++ abstraction.

Patch that will arrive there half-way (eventually needs fixing so we
still handle some special builtins):

Index: gcc/tree-optimize.c
===================================================================
--- gcc/tree-optimize.c (revision 175205)
+++ gcc/tree-optimize.c (working copy)
@@ -53,7 +53,7 @@ along with GCC; see the file COPYING3.
 static bool
 gate_all_optimizations (void)
 {
-  return (optimize >= 1
+  return (optimize > 1
          /* Don't bother doing anything if the program has errors.
             We have to pass down the queue if we already went into SSA */
          && (!seen_error () || gimple_in_ssa_p (cfun)));

[Bug rtl-optimization/49477] Should have user/debugger-oriented fine-tuning of optimizations available

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=53316

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does -Og solve this?  -Og was added at r0-118944-gbf7a718571e1722 for GCC
4.8.0.

[Bug rtl-optimization/49477] Should have user/debugger-oriented fine-tuning of optimizations available

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yes, -Og is what the bug asked for.  Well, it is supposed to be it - but it's
far from perfect yet.  Still there's now -Og which can be further tuned.