Debugging of optimized code

ssimmons@convex.convex.com (Steve Simmons)
Fri, 27 Jan 1995 03:59:42 GMT

          From comp.compilers

Related articles
[4 earlier articles]
Re: Debugging of optimized code snl@RIF.ndim.edrc.cmu.edu (Sean Levy) (1995-01-23)
Re: Debugging of optimized code conway@munta.cs.mu.OZ.AU (1995-01-24)
Re: Debugging of optimized code copperma@grenoble.rxrc.xerox.com (1995-01-24)
Re: Debugging of optimized code danhicks@aol.com (1995-01-26)
Re: Debugging of optimized code baynes@ukpsshp1.serigate.philips.nl (1995-01-26)
Re: Debugging of optimized code sam@ccnet.com (1995-01-27)
Debugging of optimized code ssimmons@convex.convex.com (1995-01-27)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
Re: Debugging of optimized code urs@engineering.ucsb.edu (1995-01-27)
Re: Debugging of optimized code miker@metaware.com (1995-01-24)
Re: Debugging of optimized code cef@geodesic.com (Charles Fiterman) (1995-01-25)
Re: Debugging of optimized code danhicks@aol.com (1995-01-27)
Re: Debugging of optimized code danhicks@aol.com (1995-01-29)
[11 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: ssimmons@convex.convex.com (Steve Simmons)
Keywords: optimize, debug
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
debugging information.


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


Thank you.


Steve Simmons
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.