On Dec 16, 2007, at 20:27, Joe Buck wrote:
I have some sympathy for going in Alexandre's direction, in that it
would be nice to have a mode that provided optimization as well as
accurate debugging. However, since preserving accurate debug
information
has a cost, I think it would be better to turn -O1, not -O2, into the
mode that Alexandre wants, where debug information is preserved.
Trying
to rework all optimizations to keep perfect debug information is going
to take forever and make the compiler worse.
Right, at the moment -O1 is far too much like -O2.
There is room for an optimization mode that is mostly local,
scales well far large programs and allows for high-quality debug
information. Fortunately, these goals seem all to match.
We could conceptually have inspection points between each source
statement and declaration, which would roughly correspond to a
use of all memory and all source variables, wether in memory or
in registers.
These inspections points would be considered potentially trapping.
This approach would still allow some scheduling. For example, loads
and arithmetic operations that are known not to trap could still
be done early. On the other hand, when breaking at any statement,
all variables can be printed.
Also, since no user-visible state can be modified by speculatively
executed instructions such as loads, such instructions should not
be tagged with their original source location information.
This would prevent the very annoying and unhelpful jumping around
the program during debugging.
The method I describe here, which roughly corresponds to the semantics
of Ada's "pragma Inspection_Point", seems relatively easy to implement
using an empty "asm" or similar.
-Geert
PS. For convenience, I'm including a snippet of the Ada 2005 standard,
the full version of which is freely available on the web.
H.3.2 Pragma Inspection_Point
1 An occurrence of a pragma Inspection_Point identifies a set of
objects
each of whose values is to be available at the point(s) during program
execution corresponding to the position of the pragma in the
compilation unit.
The purpose of such a pragma is to facilitate code validation.
Syntax
2 The form of a pragma Inspection_Point is as follows:
3 pragma Inspection_Point[(object_name {, object_name})];
Legality Rules
4 A pragma Inspection_Point is allowed wherever a declarative_item
or
statement is allowed. Each object_name shall statically denote the
declaration
of an object.
Static Semantics
5/2 An inspection point is a point in the object code corresponding
to the
occurrence of a pragma Inspection_Point in the compilation unit. An
object is
inspectable at an inspection point if the corresponding pragma
Inspection_Point either has an argument denoting that object, or has no
arguments and the declaration of the object is visible at the inspection
point.
Dynamic Semantics
6 Execution of a pragma Inspection_Point has no effect.
Implementation Requirements
7 Reaching an inspection point is an external interaction with
respect to
the values of the inspectable objects at that point (see 1.1.3).
Documentation Requirements
8 For each inspection point, the implementation shall identify a
mapping
between each inspectable object and the machine resources (such as
memory
locations or registers) from which the object's value can be obtained.
NOTES
9/2 7 The implementation is not allowed to perform "dead store
elimination" on the last assignment to a variable prior to a
point where the
variable is inspectable. Thus an inspection point has the
effect of an
implicit read of each of its inspectable objects.
10 8 Inspection points are useful in maintaining a correspondence
between
the state of the program in source code terms, and the machine
state
during the program's execution. Assertions about the values of
program
objects can be tested in machine terms at inspection points.
Object code
between inspection points can be processed by automated tools
to verify
programs mechanically.
11 9 The identification of the mapping from source program objects
to
machine resources is allowed to be in the form of an annotated
object
listing, in human-readable or tool-processable form.
