Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.6.2.16 $; site ima.UUCP Path: utzoo!decvax!cca!ima!compilers From: compilers@ima.UUCP Newsgroups: mod.compilers Subject: Object code optimization Message-ID: <136300059@ima.UUCP> Date: Thu, 16-Jan-86 11:17:00 EST Article-I.D.: ima.136300059 Posted: Thu Jan 16 11:17:00 1986 Date-Received: Fri, 17-Jan-86 01:59:24 EST Lines: 35 Approved: compilers@ima.uucp Nf-ID: #N:ima:136300059:000:1567 Nf-From: ima!compilers 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. -Saumya Debray SUNY at Stony Brook