Key observation 1 Key observation 2 Not all variables and - PDF document

Paper motivation & content Loop Bound Analysis based on a Combination of � Motivation: Safe upper loop bounds are a Program Slicing, requirement to derive safe WCET estimates � Industrial case-studies show that giving these Abstract Interpretation, bounds manually can be a major hassle and a potential source of errors and Invariant Analysis � Automatic loop-bound analyses preferable � Content: Automatic approach for deriving Andreas Ermedahl, Jan Gustafsson, upper loop bounds based on a combination Christer Sandberg, Stefan Bygde, of standard program analysis techniques: and Björn Lisper � Program slicing � Abstract interpretation Mälardalen Real - Time Research Center (MRTC) � Invariant analysis Mälardalen University, Västerås, Sweden 2 Key observation 1 Key observation 2 � Not all variables and statements affect the � Terminating loops must reach a new outcome of the exit conditions of a loop program state for each new loop iteration � If the same state is reached more than once int i,j,k=0; the loop will not terminate k++; The loop does not terminate since i is assigned the same int i=0; while(i<100) { value several times Variables j and k do not i++; while(i<100) affect the number of times j++; i++; int i=0; the loop is iterated } while(i<=100) { if(odd(i)) i++; Terminating loop else i--; } 3 4 1. Program slicing Basic idea � Used to i dentify variables and statements that � Try to bind the number of reachable states for may affect the outcome of the exit conditions variables affecting the exit conditions of a loop of a given loop � Given that the loop terminates, this number provides � Remaining variables and statements are removed an upper loop bound from the following analysis steps � Made in a three step approach… // INPUT = [10..20] // INPUT = [10..20] The OUTPUT variable 1. int foo(int INPUT) { 1. int foo(int INPUT) { does not affect the i=0; 2. 2. int OUTPUT = 0; outcome of the loop At program point p while(i<100){ exit condition 3. int i = 1; 3. int i = 1; variable i can take // p 4. while(i <= INPUT) { // p 4. while(i <= INPUT) { // p the values 0,1,...,99 Thus, statements 2, 5 5. 5. OUTPUT += 2; i++; and 8 can be removed 6. i++; 6. i++; } Thus, 100 possible program from the loop bound 7. } 7. } states within the loop = calculation 8. return OUTPUT; 8. a safe upper loop bound 9. } 9. } 5 6

2. Abstract interpretation 3. Invariant analysis � Used to derive, for each program point, a � Used to identify variables which can not be safe approximation of the values held by updated within the loop body the remaining variables � These variables can be safely ignored in the � Result used to limit the set of reachable states loop bound calculation The INPUT variable within the loop = an upper loop bound is invariant within // INPUT = [10..20] // INPUT = [10..20] the loop body An interval analysis would 1. int foo(int INPUT) { 1. int foo(int INPUT) { derive that i=[1 .. 20] and 2. 2. A safe upper loop INPUT=[10 .. 20] at point p 3. int i = 1; 3. int i = 1; bound is therefore: size(p,i) = 4. while(i <= INPUT) { // p 4. while(i <= INPUT) { // p size([1..20]) = 5. 5. A safe upper loop bound is therefore: (20 − 1+1) = 20 6. i++; 6. i++; size(i,p) ∗ size(INPUT,p)= 7. } 7. } size([1..20]) ∗ size([10..20])= Please note that the 8. (20 − 1+1) ∗ (20 − 10+1) = 8. derived loop bound 9. } 20 ∗ 11 = 220 9. } is input dependent 7 8 Program slicing details Abstract interpretation details � Our abstract domains can handle full ANSI-C � Builds upon constructing a program � Incl. pointers, arrays, structs, bit operations, overflow, … dependency graph (PDG) � We perform the analysis on the NIC intermediate code Captures data flow- and control flow- � � Widening and narrowing used for termination dependencies between statements � Gives safe result but not always the smallest one The complete program must be considered � � We support the interval domain, the congruence � Takes the input of a pointer analysis domain, and their product � We perform a step-wise slicing Product domain: i=([0 .. 9] … 0(mod 2)) 1. int i = 0; (to speed up the overall analysis): Interval domain: i=[0 .. 9] at p 2. while(i < 10){ 1) Slice upon all conditions in the program 3. // p Resulting loop bounds: 2) Make individual slices on the resulting program Congruence domain: • interval: 10 4. i += 2; slice for each loop of interest i=0(mod 2) at p • congruence: inf 5. } • product: 5 9 10 No. of loops Exact Analysis time (s) Bounded Invariant analysis details � Identifies all variables not updated within the loop body � Including updates made in functions called from the loop body � Including updates through pointers � Additional single-valued-uses analysis used � Uses the result of the abstract interpretation � Identifies variables within the loop which always have a single value when used Variable temp is not 1. while(i < 50) { // p invariant in loop body 2. temp = 1; However, analysis gives 3. i = i + temp; that temp = 1 when used 4. temp = 100; 5. } Thus, temp can be ignored in the loop bound calculation Total % bounded loops 11 12

Summary of analysis result Future w ork � 63% of the loops get upper bounded � Improved slicing on individual loops � 51% of the loops are given an exact loop bound � Will produce even smaller program slices � Usual successes: Simple loops with on one or two integer � More powerful relational abstract domains index variables in the abstract interpretation � Usual failures: Complex loops, loops with floating point � Represent constraints between values of variables index variables, or loop with exit conditions using != or == � Will probably result in smaller states (= tighter loop � Overall analysis time dominated by abstract bounds) but longer analysis times (slicing important!) interpretation � Method to guarantee loop termination � Large abstract interpretation analysis time when slicing fails to remove many variables and statements � Extension with infeasible path analysis � The product domain gives tighter loop bounds � Will be a combination of program slicing, abstract for 6 additional loops interpretation and abstract execution 13 14 The End! For more information: www.mrtc.mdh.se/projects/wcet 15