Re: Debugging of optimized code

copperma@grenoble.rxrc.xerox.com (Max Copperman)
Mon, 30 Jan 1995 14:14:53 GMT

          From comp.compilers

Related articles
[14 earlier articles]
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)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
Re: Debugging of optimized code jqb@netcom.com (1995-02-02)
Debugging of optimized code ssimmons@convex.convex.com (1995-02-02)
Re: Debugging of optimized code copperma@grenoble.rxrc.xerox.com (1995-01-30)
Re: Debugging of optimized code wicklund@Intellistor.COM (1995-01-30)
Re: Debugging of optimized code copperma@grenoble.rxrc.xerox.com (1995-01-30)
Debugging of optimized code cliffc@hpl.hp.com (1995-02-02)
Re: Debugging of optimized code bill@amber.ssd.csd.harris.com (1995-02-01)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-02-03)
Re: Debugging of optimized code ali@N2.SP.CS.CMU.EDU (Ali-Reza Adl-Tabatabai) (1995-02-03)
[1 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: copperma@grenoble.rxrc.xerox.com (Max Copperman)
Keywords: debug, optimize
Organization: Rank Xerox Research Centre - Grenoble Laboratory
References: 95-01-057
Date: Mon, 30 Jan 1995 14:14:53 GMT

Milton Barber's nice example of the kinds of things optimization can do
reminds me that I left out an important idea in my description of how
to provide a clear way of describing the "current location in code" in
source terms.


The thing to realize is that most of the instructions generated from a
statement are not of interest to the human who is debugging. If I want
to break at "x = some complicated expression", it is the instruction
that inplements the assignment that I want to break at. The fact that
the computation of x's address was moved out of a loop, that CSE was
done on part of the expression, that the loads of the operands in the
expression were scheduled arbitrarily far above the assignment---these
are all irrelevant to me the vast majority of the time.


Each side effect visible to the programmer must be mapped to the instruction or
instructions that implement it. A simple assignment would be mapped
to the instruction(s) that finally puts the right-hand-side value into the
left-hand-side location (whether memory or a register). Instructions
that are part of the address computation of the left-hand-side or
the value computation of the right-hand-side will not show up in this map,
except if they are also part of the storing of the result.


What does this buy us? Take scheduling, which can spread the instructions
generated from a statement all over the place. For the most part, it
can be ignored. Only when scheduling has caused an instruction that
implements a side effect to be moved across another instruction that
implements a side effect will any debugging anomaly be noticed; in that
case the statements will be executed out of source order.


When mapping from the source code to the machine code, you should map
from entities of interest to the programmer (changes to variables and
contol flow) to the instructions where the changes occur, which allows
the map to ignore most of the machine code. When mapping from the
machine code to the source code, you need the kind of map I described
in a previous message.


Max Copperman
--


Post a followup to this message

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