[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.