|[4 earlier articles]|
|Re: Debugging of optimized code snl@RIF.ndim.edrc.cmu.edu (Sean Levy) (1995-01-23)|
|Re: Debugging of optimized code firstname.lastname@example.org.OZ.AU (1995-01-24)|
|Re: Debugging of optimized code email@example.com (1995-01-24)|
|Re: Debugging of optimized code firstname.lastname@example.org (1995-01-26)|
|Re: Debugging of optimized code email@example.com (1995-01-26)|
|Re: Debugging of optimized code firstname.lastname@example.org (1995-01-27)|
|Debugging of optimized code email@example.com (1995-01-27)|
|Re: Debugging of optimized code firstname.lastname@example.org (Stefan Monnier) (1995-01-27)|
|Re: Debugging of optimized code email@example.com (1995-01-27)|
|Re: Debugging of optimized code firstname.lastname@example.org (1995-01-24)|
|Re: Debugging of optimized code email@example.com (Charles Fiterman) (1995-01-25)|
|Re: Debugging of optimized code firstname.lastname@example.org (1995-01-27)|
|Re: Debugging of optimized code email@example.com (1995-01-29)|
|[11 later articles]|
|From:||firstname.lastname@example.org (Steve Simmons)|
|Organization:||CONVEX News Network, Engineering (cnn.eng), Richardson, Tx USA|
|Date:||Fri, 27 Jan 1995 03:59:42 GMT|
On the subject of debugging optimized code, one the of the better papers
is from ACM SIGLAN PLDI '92 about the Convex debugger. I did much of the
work and co-authored the paper. I can reveal only what was described
in our paper (take my word, you don't want to see my family jewels).
Basically, we provide 3 areas of support that are above your typical
- Tracking source code correlation: Rather than tracking stuff at the
statement level only, we track 5 types of syntactic elements (routine,
loop, block, statement, and expression). These are deduced from the
parse tree. Each element in the intermediate language is annotated with
a list of syntactic elements to which it correlates.
As code motion is done, the list is propagated from one optimization to
the next. One big benefit is that our users can step by expression or
by block. In fact, we have a real nice primitive of "finish loop" which
means finish executing the current loop.
Users can also set breakpoints on an expression, routine, block, statement
or loop. For something like a statement, they may get several breakpoints
for one statement.
- Tracking liveness ranges of variables: A variable can be live in specific
ranges of pc boundaries. Sometimes, it is in a register while other times
the variable lies on a stack location.
In fact, we don't print the value of a variable once it is dead.
- Tracking the relationships between user defined variables and compiler
synthesized variables. In several cases, user defined variables are
replaced with synthesized variables. The best example is in the case
of loop strength reduction. Here, new variables are introduced which
replace the use of loop control variables. If the user printed the
loop control variable, he would most likely get the value at the
start of the loop.
So, we track the relationship as an expression between a loop control
variable and a synthesized variable. Then, we perform algebraic substitution
to solve the equation at debug time.
At Convex, we do have an interprocedural optimizer, the APC. It does two
major optimizations, inlining and cloning. We have not done much with
inlining; however, we have done some nice stuff with cloning. Cloning
is the process of replicating your routine and substituting some of
your formal parameters with actual values. This enables more optimizations
in the cloned routines. When you set a breakpoint on a routine, you
get all routines. Stepping tracks back to the current source.
Return to the
Search the comp.compilers archives again.