1. Partial Evaluation and Automatic Program Optimisation Lecture 1 (morning): Introduction
Michael Leuschel
Declarative Systems & Software Engineering
Dept. Electronics & Computer Science
University of Southampton
9/21/2018

2. Overview: First 2 hours Explain what these lectures are about:
Program Optimisation in general
Partial Evaluation in particular
Program Transformation, Analysis, and Specialisation
Explain why you should attend the lectures:
Why are the topics interesting ?
Why are they useful ?
Overview of the whole course

3. Part 1: Program Optimisation and Partial Evaluation: A first overview

4. (Automatic) Program Optimisation
When:
Source-to-source
during compilation
at link-time
at run-time
Why:
Make existing programs faster (10 %  500   ...)
Enable safer, high-level programming style ()
(Program verification,…)

5. Program Optimisation II
What:
constant propagation, inlining , dead-code elimination, eliminate redundant computations, change of algorithm or data-structures, …
Similar to highly optimising compilers:
much more aggressive,
(much) greater speedups and
much more difficult to control
How ?

6. Program Transformation
How:
Unfold/fold approach [Burstall,Darlington 77]
Schema-based approach
Usually not fully automatic
Why:
Program synthesis
specification  executable program
Program optimisation:
Change data-structure, algorithm, …
Program specialisation, ...

7. Program Transformation: Unfold/fold
Initial
Program P0
Program P1
Final
Program Pn
...
unfold/fold
step
unfold/fold
step
Under some conditions:
Same semantics
Same termination properties
Better performance

8. Program Analysis What: Why:
Find out interesting properties of your programs:
Values produced, dependencies, usage, termination, ...
Why:
Verification, debugging
Type checking
Check assertions
Optimisation:
Guide compiler (compile time gc, …)
Guide source-to-source optimiser

9. Program Analysis II How: Techniques:
Rice’s theorem: all non-trivial properties are undecidable !
 approximations or sufficient conditions
Techniques:
Ad hoc
Abstract Interpretation [Cousot’77]
Type Inference

10. Abstract Interpretation
Concrete domain
Abstract Interpretation …
Principle:
Abstract domain
Abstract operations:
safe approximation of concrete operations
Result:
Correct
Termination can be guaranteed
 Decidable approximation of undecidable properties N- N+
Abstract domain
N+ + N+ = N+
N = N+
...

11. Program Specialisation
Drawing
Program P
Program Specialisation
What:
Specialise a program for a particular application domain
How:
Partial evaluation
Program transformation
Type specialisation
Slicing P’

12. Overview Partial Program Evaluation Transformation Program
Specialisation
Program Optimisation

13. Part 2: A closer look at partial evaluation: First Steps

14. A closer look at PE Partial Evaluation versus Full Evaluation Why PE
Issues in PE: Correctness, Precision, Termination
Self-Application and Compilation

15. Full Evaluation Full input Computes full output function power(b,e) is
if e = 0 then 1
else
b*power(b,e-1)

16. Partial Evaluation Only part of the input
 produce part of the output ?
power(?,2)
 evaluate as much as you can
 produce a specialized program
power_2(?)

17. PE: A first attempt Small (functional) language: Basic Operations:
constants (N), variables (a,b,c,…)
arithmetic expressions *,/,+,-, =
if-then-else, function definitions
Basic Operations:
Evaluate arithmetic operation if all arguments are known
2+3  =4  false x+(2+3)  x+5
Replace if-then-else by then-part (resp. else-part) if test-part is known to be true (resp. false)
function power(b,e) is
if e = 0 then 1
else
b*power(b,e-1)

18. Example: power power(?,2) power(?,1) Residual code:
function power(b,2) is
if false then 1
else
b*power(b,2-1)
function power(b,2) is
if 2 = 0 then 1
else
b*power(b,e-1)
function power(b,2) is
if e = 0 then 1
else
b*power(b,e-1)
Residual code:
function power_2(b) is
b*power_1(b)
power(?,1)
function power(b,1) is
if e = 0 then 1
else
b*power(b,e-1)
function power(b,1) is
if false then 1
else
b*power(b,1-1)
function power_1(b) is
b*power_0(b)

19. Example: power (cont’d)
function power(b,0) is
if 0 = 0 then 1
else
b*power(b,e-1)
function power(b,0) is
if 0 = 0 then 1
else
b*power(b,e-1)
function power(b,0) is
if e = 0 then 1
else
b*power(b,e-1)
Residual code:
function power_0(b) is 1

20. Example: power (cont’d)
Residual code:
function power_2(b) is
b*power_1(b)
function power_1(b) is
b*power_0(b)
function power_0(b) is 1
What we really, really want:
function power_2(b) is
b*b

21. Extra Operation: Unfolding
≈ evaluating the
function call operation
Replace call by definition
function power(b,2) is
if 2 = 0 then 1
else
b* (if 1 = 0 then 1
else b* (if 0 = 0 then 1
else b*power(b,-1)))
function power(b,2) is
if 2 = 0 then 1
else
b*power(b,1)
function power(b,2) is
if 2 = 0 then 1
else
b* (if 1 = 0 then 1
else b*power(b,0))
Residual code:
function power_2(b) is
b*b*1
≈ SQR function

22. PE: Not always beneficial
power(3,?)
Residual code:
function power(3,e) is
if e = 0 then 1
else
3*power(3,e-1)
function power(3,e) is
if e = 0 then 1
else
b*power(b,e-1)
function power_3(e) is
if e = 0 then 1
else
3*power_3(e-1)

23. Part 2: Why Partial Evaluation (and Program Optimisation)?

24. Constant Propagation Static values in programs
function my_program(x) is …
y := 2* power(x,3)
captures inlining and more
function my_program(x) is …
y := 2* x * x * x

25. Abstract Datatypes / Modules
Get rid of inherent overhead by PE
function my_program(x) is …
if not empty_tree(x) then
y := get_value(x)…
+ get rid of redundant run-time tests
function my_program(x) is …
if x != null then
y := x->val …

26. Higher-Order/Reusing Generic Code
Get rid of overhead  incite usage
function my_program(x,y,z) is …
r := reduce(*,1,map(inc,[x,y,z]))
function my_program(x,y,z) is …
r := (x+1)*(y+1)*(z+1)

27. Higher-Order II Can generate new functions/procedures
function my_program(x) is …
r := reduce(*,1,map(inc,x))
function my_program(x) is …
r := red_map_1(x)
function red_map_1(x) is
if x=nil then return 1
else return x->head* red_map_1(x->tail)

28. Staged Input Input does not arrive all at once 5 2 2.1 42
my_program (x , y , z) … 42

29. Examples of staged input
Ray tracing calculate_view(Scene,Lights,Viewpoint) Interpretation interpreter(ObjectProgram,Call) prove_theorem(FOL-Theory,Theorem) check_integrity(Db_rules,Update) schedule_crews(Rules,Facts)
Speedups
2: you get your money back
10: quite typical for interpretation overhead
(and even ∞): possible

30. Ray Tracing
Static

31. Why go beyond partial evaluation
Improve algorithms (not necessarily PS):
Tupling
Deforestation
Superlinear speedups
Non-executable  executable programs
Software Verification, Inversion, Model Checking

32. Tupling
Corresponds to
loop-fusion

33. Deforestation

34. Part 3: Issues in Partial Evaluation and Program Optimisation
Efficiency/Precision
Correctness
Termination
Self-application

35. Correctness Language Semantics
Power/Elegance: unfolding LP easy, FP ok, C++ aargh
Modularity: global variables, pointers
Semantics
Purely logical
Somewhat operational (termination,…)
Purely operational
Informal/compiler
admissive
restrictive

36. Programming Language for Course
Lectures use mainly LP
Don’t distract from essential issues
Nice programming paradigm
A lot of room for speedups
Techniques can be useful for other languages, but
Correctness will be more difficult to establish
Extra analyses might be required (aliasing, flow analysis, …)

37. Efficiency/Precision
x := 2+y; p(x)
y=5  p(7)
Unfold enough but not too much
Enough to propagate partial information
But still ensure termination
Binding-time Analysis (for offline systems):
Which expressions will be definitely known
Which statements can be executed
Allow enough polyvariance but not too much
Code explosion problem
Characteristic trees
p(7) p(9) p(11) p(13) ...

38. Termination Who cares PE should terminate when the program does
PE should always terminate
" within reasonable time bounds
State of the art

39. Self-Application Principle: Why:
Write a partial evaluator (program specialiser,…) which can specialise itself
Why:
Ensures non-trivial partial evaluator
Ensures non-trivial language
Optimise specialisation process
Automatic compiler generation !

40. Compiling by PE Call2 Call1 Call3 Result1 Object Program P Interpreter

41. Compiler Generation by PE
Object Program R
static
Object Program Q
Object Program R
Object Program P
Object Program Q
Object Program P
Interpreter I PE
PE’
I-PE
= Compiler !
Useful for:
Lge Extensions,
Debugging,
DSL,...
P-Interpreter
Q-Interpreter
R-Interpreter

42. Cogen Generation by PE Interpreter R static Interpreter Q
Interpreter P
Interpreter Q
Interpreter P PE
PE’
PE’’
PE-PE
= Compiler
Generator !
P-Compiler
3rd Futamura
Projection
Q-Compiler
R-Compiler

43. Part 4: Overview of the course (remainder)

44. Overview of the Course: Lecture 1 (remainder)
Partial Evaluation of Logic Programs: First Steps
This afternoon, April 20th:
A short (re-)introduction to Logic Programming
How to do partial evaluation of logic programs (called partial deduction): first steps
Outcome:
Enough knowledge of LP to follow the rest
Concrete idea of PE for one particular language

45. Overview of the Course: Lecture 2
(Online) Partial Deduction: Foundations, Algorithms and Experiments
Next week, April 27th:
Correctness criterion and results
Control Issues: Local vs. Global; Online vs. Offline
Local control solutions: Termination
Global control: Ch. trees, WQO's at the global level
Relevance for other languages and applications
Full demo of Ecce system
Outcome:
How to control program specialisers (analysers, ...)
How to prove them correct

46. Overview of the Course: Lecture 3
Self-application and compiler generation
May 4th:
Principle of self-application, history
Cogen by hand principle
How to achieve cogen by hand for logic programs
Binding-time analysis by abstract interpretation (POS)
How to handle extra logical features
Demo of the logen system
Outcome:
How to achieve (very) fast specialisation
How to automatically generate compilers

47. Overview of the Course: Lecture 4
Extending Partial Deduction: Integrating Unfold/Fold and Abstract Interpretation
May 11th:
Unfold/Fold vs PD
Going from PD to Conjunctive PD
Control issues, Demo of Ecce
Abstract Interpretation vs Conj. PD and Unfold/Fold
Integrating Abstract Interpretation
Applications (+ Demo): Infinite Model Checking
Outcome
How to do very advanced/fancy optimisations

48. Summary (first 2 hours): What to know for the exam
Terminology:
Program Optimisation, Transformation, Analysis, Specialisation, PE
Basics of PE and Optimisation in general
Uses of PE and Program Optimisation
Common compiler optimisations
Enabling high-level programming
Staged input, optimising existing code
Self-application and compiler generation