|Object code optimization compilers@ima.UUCP (1986-01-10)|
|Re: Object code optimization compilers@ima.UUCP (1986-01-13)|
|Object code optimization compilers@ima.UUCP (1986-01-16)|
|Date:||16 Jan 86 16:17:00 GMT|
|Posted:||Thu Jan 16 11:17:00 1986|
[from allegra!sbcs!debray (Saumya Debray)]
It isn't entirely surprising that transforming a HLL program P1 to an
equivalent "optimal" (!?) HLL program P2 and then generating code from
P2 might not always yield the best results. The virtual machine
corresponding to the high-level language is really very different from
that corresponding to the low-level one, and one might expect their cost
criteria to be different as well.
I have a couple of comments against restricting optimization
_exclusively_ to low-level code, however:
(1) The idea behind code optimization is to preserve equivalence
between programs at the HLL level while improving the estimated cost
at the low level. However, if optimization is restricted to object
code, then we are necessarily required to preserve equivalence
at the object code level. This may be overly restrictive, since it
may not take into account the fact that certain aspects of the
object code programs are irrelevant at the HLL level.
(2) The level of abstraction provided by a HLL may make certain
optimizations much simpler at that level than at the object code
level. For example, the transformation of a recursive program
to compute the factorial function,
fact(N) = if N = 0 then 1 else N * fact(N-1)
to tail-recursive and thence to iterative form is fairly
straightforward at the HLL level, using the associativity of *. It's
not obvious to me how the corresponding transformation would go
working only on object code.
SUNY at Stony Brook
Return to the
Search the comp.compilers archives again.