Re: Partial evaluation vs flow-graph analysis

mossin@diku.dk (Christian Mossin)
25 May 1997 12:47:37 -0400

          From comp.compilers

Related articles
[4 earlier articles]
Re: gawk memory leak pfoxSPAMOFF@lehman.com (Paul David Fox) (1997-04-13)
Purify patent (was Re: gawk memory leak) elan@jeeves.net (Elan Feingold) (1997-05-04)
Re: Purify patent (was Re: gawk memory leak) krish@cs.purdue.edu (Sailesh Krishnamurthy) (1997-05-08)
Re: Purify patent (was Re: gawk memory leak) pfox@lehman.com (Paul David Fox) (1997-05-13)
Re: Purify patent (was Re: gawk memory leak) boehm@mti.mti.sgi.com (Hans-Juergen Boehm) (1997-05-17)
Partial evaluation vs flow-graph analysis fabre@gr.osf.org (Christian Fabre) (1997-05-22)
Re: Partial evaluation vs flow-graph analysis mossin@diku.dk (1997-05-25)
Re: Partial evaluation vs flow-graph analysis Jacques.Noye@emn.fr (1997-05-25)
Re: Partial evaluation vs flow-graph analysis thorn@spamblock.lalla.irisa.fr (Tommy Thorn) (1997-05-27)
Partial evaluation in imperative languages. cef@geodesic.com (Charles Fiterman) (1997-05-30)
Re: Partial evaluation in imperative languages. monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-31)
Re: Partial evaluation in imperative languages. cliffc@risc.sps.mot.com (Cliff Click) (1997-06-02)
| List of all articles for this month |
From: mossin@diku.dk (Christian Mossin)
Newsgroups: comp.compilers,comp.lang.functional
Date: 25 May 1997 12:47:37 -0400
Organization: Department of Computer Science, U of Copenhagen
References: 97-03-165 97-04-020 97-04-022 97-04-037 97-04-070 97-05-019 97-05-090 97-05-162 97-05-216 97-05-254
Keywords: optimize, analysis

Christian Fabre <fabre@gr.osf.org> writes:


>Partial evaluation seems to be a hot topic in the compiler field
>nowaday. As far as we've understood, the basic idea is to partially
>evaluate (sic) a program based on the information we are able to
>gather about its arguments. This requires some sort of intrepreter
>(or is it a meta-interpreter?) to compute the simplified program.


>Did we miss something obvious so far?


I don't think so --- usually "the information we are able to gather
about its arguments" means the actual _values_ of some (static)
argument that are constant for a number of runs.


>This makes us think that the kind of tasks well suited for partial
>evaluation can also be done, for most of them, with "older" techniques
>such as flow-graph equations.


>So our question is what kind of optimisations will partial evaluation
>make possible that are out of reach of a classical optimizer (and
>vice-versa)?


Conceptually, a partial evaluator is nothing but a powerful
interprocedural constant propagation transformation (where the values
of the static parameters are inserted as constants in the program
text), which allows loop unrolling, call unfolding, context
propagation, procedure cloning.


On the other hand, most program optimizations can be seen as special
instances of partial evaluation...


>Is there some paper comparing the two techniques?


In chapter 17 of the book "Partial Evaluation and Automatic Program
Transformation" by Jones, Gomard and Sestoft there is some discussion
of the relation to Fold/Unfold and to deforestation.


>Also, most of the papers talk about PE in the context of functional
>languages like ML or Haskell. Is this technique also usefull/usable
>for imperative languages like C, C++, Java or Eiffel?


Look at


http://www.diku.dk/research-groups/topps/activities/cmix.html


for a partial evaluator for C. There is some research on PE of Java at
DIKU and (I believe) in France --- I wouldn't expect any conceptual
difficulties.


Cheerio,


Christian
--
Christian Mossin E-mail: mossin@diku.dk
DIKU, Department of Computer Science Phones: Off: +45 35 32 14 06
Universitetsparken 1, DK-2100 Copenhagen East, DENMARK Fax: +45 35 32 14 01
http://www.diku.dk/research-groups/topps/personal/mossin.html
--


Post a followup to this message

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