1. Growth-rate analysis of programs: the quest for decidability
A VERIFICATION PROBLEM: Given a program p, does p run in polynomial time?
Focus on decidability in weak programming languages
Amir M. Ben-Amram
Joint work with
Lars Kristiansen, Neil Jones, Aviad Pineles

2. Outline Introduce the problem
Growth-rate analysis of a simple language: [BJK ’08]
Extensions and open problems [B ‘10], [BK ‘12], [BP ‘14]

3. Cost analysis of programs
A topic in automated program analysis
Wegbreit 1975: a system to analyse the complexity of LISP programs.
Many current (or recent) projects, e.g. COSTA, Safe, SPEED …
There are several practical motivations – and theoretical challenges
(4) several reasons for interest: system engineering, efficiency bugs, paralleization, program generation, AI challenge. Different goals require different degrees of precision
REVERSE(L)  if NULL(L) then {} else APPEND(REVERSE(CDR(L)), CONS(CAR(L), {}))
c0 + c1n + c2n2

4. Decidability of program analysis problems
No “sound but incomplete” solutions
proofs, not benchmarks & competitions
Study what “weak languages” can be analysed, and how complex the analysis is.
Very simple
Language
analysis P
Modest
Language
decidable, but harder
Strong
Language
undecidable

5. Simple “loop programs” have been studied wrt decidability
Kasai & Adachi, JCSS 1980
Kristiansen and Niggl, TCS 2004
Niggl & Wunderlich, SICOMP 2006
Jones & Kristiansen, TOCL 2009
Ben-Amram, Jones & Kristiansen, CiE 2008
Ben-Amram, DICE 2010
No intention to give details, but maybe state aloud the last part (in ICC, complexity classes like PTIME are related to weak programming languages)
Focus on identifying a complexity class (polynomial time?)
“Simple” decision problem
Influence from the field of ICC (Implicit Comp. Complexity)

6. Simple “loop programs” have been studied wrt decidability
In these programs loops are explicitly bounded
Asking about time complexity, etc., is equivalent to
asking about the growth rate of variables
Hence “the polynomial growth-rate problem”
do X times { … } not while B do { … }
(Some natural variants, e.g., linear)

7. loop X {
Z := Y ;
Y := Y+Z }
Is the running time polynomial in the initial values?
Is the final value of a given variable polynomial?
YES, IT IS
Y, Z grow exponentially

8. Important to deal correctly with arithmetic and geometric sequences
loop X {
Z := X ;
Y := Y+Z }
Is the running time polynomial in the initial values?
Is the final value of a given variable polynomial?
YES, IT IS
THEY ALL ARE
Important to deal correctly with arithmetic and geometric sequences

9. loop N1 { loop N2 { Z := Y ; if … then Y := X else X := Z } Z := Z+Y
as examples shows, not always easy.

10. CiE 2005 Jones and Kristiansen (subsequently in ACM TOCL)
e Expression ::= X | (e + e) | (e  e)
C  Command ::= skip
| X := e
| C1 ; C2
| loop X {C}
| choose C1 or C2
ANALYSIS
SOUND, BUT
INCOMPLETE

11. Ben-Amram, Jones and Kristiansen
CiE 2008
Ben-Amram, Jones and Kristiansen
e Expression ::= X | (e + e) | (e  e)
C  Command ::= skip
| X := e , X : e
| C1 ; C2
| ?loop X {C}
| choose C1 or C2

12. Simplified Language Features
Arithmetics reduced to + ,  (say over )
Conditionals  non-determinism
choose C1 or C2
Loops  bounded loops
?loop X { C }
do C (at most) X times
weak assignment X : e
new value of X is unknown but [0,e]

13. Ben-Amram, Jones and Kristiansen
CiE 2008
Ben-Amram, Jones and Kristiansen
e Expression ::= X | (e + e) | (e  e)
C  Command ::= skip
| X := e , X : e
| C1 ; C2
| ?loop X {C}
| choose C1 or C2
DECIDABLE
in PTIME

14. Outline Introduce the problem
Growth-rate analysis of a simple language: [BJK ’05]
Extensions and open problems [B ‘10], [BK ‘12], [BP ‘14]
say: to evaluate the limitations, I look at related work.

15. A list of interesting extensions
In [BJK ‘08], the following simplifications were crucial:
loops are non-deterministic, no concrete conditionals
programs are compositional (critical for the handling of loops)
no constants
no subtraction/decrement

16. 1. Definite loops
[BK ’11]
Polynomial growth is undecidable for the language:
* !loop = definite loop
e Expression ::= X | (e + e) | (e  e)
C  Command ::= skip
| X := e , X : e
| C1 ; C2
| !loop X {C}
| choose C1 or C2
(note to self - := can also be “weak assignment” )

17. 1. Definite loops
[BK ’11]
Polynomial growth is undecidable for the language:
C  Command ::= X := X+Y
| C1 ; C2
| !loop X {C}
* !loop = definite loop
(note to self - := can also be “weak assignment” )

18. 1. Definite loops
[BK ’11]
Polynomial growth is undecidable for the language:
C  Command ::= X := X+Y
| C1 ; C2
| !loop X {C}
* !loop = definite loop
(note to self - := can also be “weak assignment” )
X : X+Y ??

19. 1. Definite loops
[BK ’11]
Polynomial growth is undecidable for the language:
C  Command ::= X := X+Y
| C1 ; C2
| !loop X {C}
* !loop = definite loop
(note to self - := can also be “weak assignment” )
X :  X+Y
UNDECIDABLE

20. 2. Flowchart programs [BP ’16]
Practical work often uses “flowchart programs”
JBC, LLVM, ad-hoc representations
A challenge to our methods: programs not compositional,
loops not explicitly bounded, and are managed using operations that we do not hope to handle (yet)
(note to self - := can also be “weak assignment” )

21. An “abstract and conquer” setting
FRONT END
BACK END
source program
Annotated/ abstracted
program
loop analysis
analysis
A common setup of a program analysis tool which makes use of a weak language in the back-end, where problems may be decidable. 30 30

22. An “abstract and conquer” setting
FRONT END
BACK END
source program
Annotated/ abstracted
program
loop analysis
analysis
Loop-Annotated Flowcharts 31 31

23. Loop-annotated flowcharts
A program-representation suitable for the result of a prior analysis (front end) - loop bounds determined
- arithmetics simplified
We proved PTIME-decidability for these programs by transforming them to a structured language.

24. 3. Constants e Expression ::= X | X+Y | XY | 0 | 1
C  Command ::= skip
| X := e
| C1 ; C2
| loop X {C}
| choose C1 or C2
OPEN 33

25. 3. Constants e Expression ::= X | X+Y | XY | 0 C  Command ::= skip
| X := e
| C1 ; C2
| loop X {C}
| choose C1 or C2
Decidable (DICE 2010)
PSPACE-complete 34

26. Why the jump in complexity?1
Why the jump in complexity?
Z := Z+YX
X X'
Y Y'
Z Z'
Z := Z+YX
given Y=0
X X'
Y Y'
Z Z'
Intuitively, for n variables, 2n cases must be described.

27. Summary & Some guesswork
definite loop: no chance.
unstructured programs: some progress.
constants: solved for 0 only.
Conjecture: with 0, 1 it is decidable
decrement: ( with { X=0 } X := X  1 {X=0} )
Conjecture: it is decidable
5. if all conjectures are true: weak counter programs

28. The problem of tight bounds
The polynomial degree problem is: Given a program (in a language where polynomiality is decidable), and a constant d, is the number of steps a polynomial of degree at most d ?
PSPACE-hard
decidability open
(but conjectured)

29. The analysis of the CiE’08 language
We give a set of proof rules for "dependency facts“ (in what way does an output value depend on the inputs?)
This may be seen as a functional abstract domain. The abstraction of a command is the set of all dep. facts that come out of the proof rules.

30. Dependencies have types  {1,1+,2,3} Z := Z+YX  X  X' ( copy dependence ) Z := Z+YX  X  Z’ ( polynomial dependence ) Z := Z+YX  Z  Z’ ( additive dependence ) loop X { Y:=Y+Y }  X  Y’ ( super-polynomial) Another kind of dependence – the simultaneous flow Z := Z+X  Note – these express a definite possibility The answer is "not polynomial" if we can prove any fact of the kind P  X  Y’ 1 2 1+ 3
Remark on the 1+ that we’ll see later why it’s there
X  Z’
Z  Z’ 3

31. Proof rules for composite commands
C1 |― D1
C2 |― D2
choose C1 or C2 |― Di i=1,2
C1 ; C2 |― D1  D2
The proof rules allow for compositionally computing the
set of possible dependencies for any command

32. Loops
C |― M (set of deps)
loop X { C } |― ??

33. Loops X1 X1 X2 X2 M X3 X3 1 1+ Example: loop X3 { X2 := X2 + X1 }
The effect of the loop is:
X2  X2 + X3X1 1 1+

34. Iteration closure X1 X1 X2 X2 X3 X3 1 1+ X2 X2 M2 X1 X1 X2 X2 X3 X3 1
What’s missing is the implicit flow
X X1
X X2
X X3 1 2 1+
Fixed point:

35. Loop Correction Rule 1 (implicit flow – arithmetic series):
If Xi 1+ Xi in the loop,
add X 2 Xi
Rule 2 (implicit flow – geometric series):
If Xi 2 Xi in the loop,
add X 3 Xi
E.g., loop X3 { X1 := 2X1 }
(1) is why we need the 1+

36. p.s. Analysis runs in polynomial time.
And that was it !
e Expression ::= X | (e + e) | (e  e)
C  Command ::= skip
| X := e , X : e
| C1 ; C2
| ?loop X {C}
| choose C1 or C2
p.s. Analysis runs in polynomial time.

37. Tricks with !loop

38. loop L2 {
(A,B) := (X,Y);
loop L1 {
(A,B) := (B,A) };
R1 := A;
(A,B) := (Y,X);
(A,B) := (B,A);
R2 := A;
A := R1 +R2; }
R1  X or Y
depending on L1 mod 2
R2  X or Y
depending on L1 mod 2
(cases reversed!)

39. loop L2 {
A := A +B; }
we see that the program is feasible. But the deduction, involving a case analysis wrt divisibility, was beyond the scope of our method.

40. Undecidability Proof Language L3
Lars says it's well-known. But I will give an explanation anyway.
e Expression ::= X | X+Y | XY | 0 | 1
C  Command ::= skip
| X := e
| C1 ; C2
| !loop X {C}
| if ? then C1 else C2

41. It is well-known that feasibility is undecidable for COUNTER PROGRAMS:
e Expression ::= X | X+1 | X-1 | 0
C  Command ::= skip
| X := e
| C1 ; C2
| !loop X {C}
| if X=0 then C

42. X := 0; Z := 0; loop Y { X := Z ; Z := Z+1}
We show that L3 can simulate the missing instructions.
Gadget 1:
X := 0; Z := 0; loop Y { X := Z ; Z := Z+1}
simulates X := Y-1
Gadget 2: simulates if X=0 then C
(V1, ...,Vn) := (V1, ...,Vn);
C; loop X {(V1, ...,Vn) := (V1, ...,Vn) }
technical comments (not important)
(1) X, Y different variables
(2) we assume that C does not affect X ^
affects V1 ,...,Vn

43. L4 e Expression ::= X | X+Y | XY | 0 | 1 C  Command ::= skip
Removing what we didn't use...
e Expression ::= X | X+Y | XY | 0 | 1
C  Command ::= skip
| X := e
| C1 ; C2
| !loop X {C}
| if ? then C1 else C2

44. L5 e Expression ::= X | X+Y | XY | 0 | 1 C  Command ::= skip
Look how simple it is!
e Expression ::= X | X+Y | XY | 0 | 1
C  Command ::= skip
| X := e
| C1 ; C2
| !loop X {C}
| if ? then C1 else C2

45. L5
C  Command ::= X := Y
| X := X+Y
| C1 ; C2
| !loop X {C}

46. C; loop X {(V1, ...,Vn) := (V1, ...,Vn) }
We can still simulate if X=0 then C
Here's another gadget:
(V1, ...,Vn) := (V1, ...,Vn);
C; loop X {(V1, ...,Vn) := (V1, ...,Vn) } ^
(V1, ...,Vn) := (V1, ...,Vn);
CU; (C with V's renamed to U's)
loop X {
(V1, ...,Vn) := (U1, ...,Un);
(U1, ...,Un) := (V1, ...,Vn) } ^
Simulates if X=1 then C

47. Conclusion: we can simulate the constants 0, 1 .
Use dedicated variables K0, K1
Replace each command C by
if K0=0 then if K1=1 then C
C  Command ::= X := Y
| X := X+Y
| C1 ; C2
| !loop X {C}
UNDECIDABLE