Control Flow Analysis for WCET Analysis Bjrn Lisper School of - - PowerPoint PPT Presentation

Control Flow Analysis for WCET Analysis

Björn Lisper School of Innovation, Design, and Engineering Mälardalen University bjorn.lisper@mdh.se 2017-07-18

Dagstuhl Seminar on Resource Bound Analysis

Standard Scheme for WCET Analysis

WCET analysis is typically broken down into the following steps:

• Constrain possible program flows (“high-level”, or “flow” analysis)
• Estimate hardware impact to bound WCET for program fragments

(“low-level” analysis)

• Use information to produce a safe WCET estimate (calculation)

This talk is about how to constrain the program flow Sequential programs only – for parallel programs the analysis is harder to decompose

Dagstuhl Seminar on Resource Bound Analysis 1

Structure of WCET Analysis

Low−level analysis Calculation Flow analysis Annotations HW timing model Program source Object code Compiler Value analysis WCET estimate

Dagstuhl Seminar on Resource Bound Analysis 2

Control Flow Analysis for WCET Calculation

Purpose: find constraints on the number of times different program parts can execute:

• Loop iteration bounds (needed to bound WCET)
• Infeasible path constraints (can improve precision)
• . . .

Independent of the timing model – standard methods and frameworks for program analysis can be adapted Still hard – a perfect solution would solve Turing’s Halting Problem Methods must be approximate. Constraints may have to be added manually. The goal is to minimise the need for this

Dagstuhl Seminar on Resource Bound Analysis 3

Example

Dagstuhl Seminar on Resource Bound Analysis 4

Example: Loop Bound

Loop iteration bound depends on value of i when foo is called Say that 1 ≤ i ≤ 10. Then the bound is 100 Not entirely trivial to find out for a human Can be found automatically, given this information on i

Dagstuhl Seminar on Resource Bound Analysis 5

Example: Infeasible Path

Conditions B and E cannot both be true at the same time Thus, C and F cannot both be executed The path A - B - C - E - F - G is infeasible This info can sometimes be used to obtain a tighter WCET estimate (We have found up to 30% improvement on real industrial code)

Dagstuhl Seminar on Resource Bound Analysis 6

The Implicit Path Enumeration Technique (IPET)

Program flow constraints usually formulated in the IPET model Based on a Control-Flow Graph (CFG) program representation:

i := 0 start i < n i < n−10 stop false B1 B2 false true i := i+1 true n0 n1 n2 n3 n4 n5

Various refinements exist (like Jan’s Abstract Execution Graphs)

Dagstuhl Seminar on Resource Bound Analysis 7

For each node ni (basic block) in the CFG, let ti be an upper local WCET bound for ni Define an execution counter xi for each ni:

• Initialised to 0
• Incremented by 1 each time ni is executed
• “Virtual variables”, not present in the code
• Their final values characterise the execution path for a complete run

max xiti over all paths provides a safe WCET bound

Dagstuhl Seminar on Resource Bound Analysis 8

WCET Bounds Estimation in the IPET Model

WCET estimation (calculation) becomes a maximization problem: max

• i

xiti subject to flow constraints Ax ≤ b An Integer Linear Programming (ILP) problem The aim of flow analysis is to find the system of inequalities Ax ≤ b

Dagstuhl Seminar on Resource Bound Analysis 9

Program Flow Constraints as Linear Inequalities

Many flow constraints can indeed be expressed as linear constraints on execution counters:

• xi ≥ 0 for all ni (counters must be non-negative)
• Structural flow constraints (from CFG structure):

– For each node = start, stop, input counters = output counters – xi = 1 if ni is the start or stop node of the CFG

• Semantic constraints:

– Loop iteration bounds (capacity bounds): xi ≤ c – Infeasible paths (mutual exclusivity): xi + xj ≤ c – Relative bounds (often in nested loops): xi = c · xj

Dagstuhl Seminar on Resource Bound Analysis 10

A Comparison with Control Flow Analysis for Functional Programs

There is Control Flow Analysis (CFA) for higher-order functional programs This is something different CFA estimates, for each function call, which functions may be applied. Example [Nielson et. al. 2005]:

let f = fn x => x 1; g = fn y => y+2; h = fn z => z+3 in (f g) + (f h)

For x 1, f g, f h: which functions may be applied?

Dagstuhl Seminar on Resource Bound Analysis 11

CFA for WCET vs. CFA for Functional Programs

CFA for WCET analysis is done on low level formats (binaries, C) In this context, CFA for functional programs corresponds to analysis of function pointers Certainly needed to do CFA for WCET for programs with such pointers! For functional programs, CFA for WCET corresponds to an analysis bounding the # of function calls Bounding the # of loop iterations ∼ bounding recursion depth Useful for resource analysis of functional programs?

Dagstuhl Seminar on Resource Bound Analysis 12

Classes of Control Flow Analysis Methods for WCET

Syntactically oriented methods: Typically for loop iteration bounds. Matches loop structure to common patterns, identifying start, stop, step

for( var = start; var < stop; var = var + step ) { ... }

On source level (common syntactic programming patterns), but also binary level (typical loop patterns generated by some specific compiler) Pros: simple to implement, fast Cons: sensitive to syntax. Will fail in many cases. May be unsound

Dagstuhl Seminar on Resource Bound Analysis 13

Classes of Control Flow Analysis Methods (II)

Semantically oriented methods: Loop iteration bounds as well as other flow constraints Analysis based on the semantics of the program rather than syntax Methods often based on abstract interpretation (also model checking, symbolic execution). Typically some kind of fixed-point iteration is used Pros: Less sensitive to syntax. Can be made more precise. More general classes of flow constraints. Possible to play around with tradeoff between precision and analysis speed Cons: can be resource-consuming. Tools may be complex and expensive to implement

Dagstuhl Seminar on Resource Bound Analysis 14

Approach 1: Identify Loop Counter Parameters

Idea: find start value, step, value at exit for loop counters Once known, an upper bound on the # of iterations can be calculated Several approaches have been proposed, based on techniques like:

• data flow analysis
• solving Presburger formulas
• abstract interpretation

Pros: methods can be made simple and fast. Many loops have easily identifiable loop counters, and can be handled well Cons: restricted to loops with loop counters

Dagstuhl Seminar on Resource Bound Analysis 15

Identifying Loop Counter Parameters: Example

A method based on abstract interpretation (value analysis). Originates from

• U. Saarland (Cullmann 2006)

Steps (for a given loop):

• 1. Identify loop counter
• 2. Bound the initial value of the loop counter
• 3. Find bounds for the loop counter increment (or decrement)
• 4. Analyze loop exits w.r.t. usage of the loop counter, deriving upper (or

lower) bounds for the counter

• 5. Calculate upper bounds on # of iterations

Bounds on values are found by a value analysis (typically interval analysis), based on abstract interpretation

Dagstuhl Seminar on Resource Bound Analysis 16

Example

/* i in interval [1..4] at entry */ s = 0; n = 100; while i < n do s = s + a[i]; if complex_condition then i = i + 2 else i = i + 3;

Potential loop counters: i, s (updated in loop). However only i can affect the exit condition, thus identified as loop counter Initial bound for i: [1..4] (obtained by value analysis) Bound on increment of i: [2..3] (obtained by value analysis) Upper bound on i: [99..99] (value analysis of exit condition) Loop iteration bound: (99 − 1)/2 = 49

Dagstuhl Seminar on Resource Bound Analysis 17

Approach 2: Abstract Execution

Originates from MDH (Gustafsson 2000), (Gustafsson et. al. 2006) Finds constraints on execution counters through a kind of symbolic execution of the program – “abstract execution” (AE) AE executes the program with abstract states, representing sets of real (“concrete”) states It can be seen as a a kind of value analysis (abstract interpretation) Each abstract state transition corresponds to many possible concrete state transitions In principle any abstract domain can be used for the abstract states The interval domain is commonly used, due to speed and simplicity

Dagstuhl Seminar on Resource Bound Analysis 18

Abstract Execution (II)

AE can be seen as a very context-sensitive value analysis (differing between all loop iterations) Contrary to a conventional value analysis, it does not compute an abstract state for each program point: it’s more similar to a real execution with a concrete state Uses a kind of instrumentation to successively collect constraints on execution counters during AE of loops Abstract states can be split at conditions. This can result in many states To counter this, abstract states can be merged. This can be used to control the number of abstract states. Merge points can be placed in the CFG. Merging can affect the precision, though

Dagstuhl Seminar on Resource Bound Analysis 19

Abstract Execution (III)

Pros: can be precise. Can also compute more general constraints, like for infeasible paths. Can in principle use any abstract domain, not à priori restricted to loops with numerical loop counters. Cons: can be time-consuming, potentially poor scalability. Risk of nontermination (can be fixed, though)

Dagstuhl Seminar on Resource Bound Analysis 20

Example

i = INPUT; // i = [1..4] #p = 0; while (i < 10) { // point p #p = #p + 1; ... i=i+2; } // point q (a) Code example p i at p i at q 1 [1..4] impossible 2 [3..6] impossible 3 [5..8] impossible 4 [7..9] [10..10] 5 [9..9] [10..11] 6 impossible [11..11] (b) Analysis min. #p: 3 max. #p: 5 (c) Result

(#p is the execution counter for program point p)

Dagstuhl Seminar on Resource Bound Analysis 21

Example, Discussion

Note how we collected information about the lower and upper bounds of #p during the AE of the loop This scheme can be extended to record a number of more complex flow constraints, including infeasible nodes, infeasible pairs of nodes, and more general infeasible paths After the AE of the loop, three abstract states reside at q for analysis of the rest of the program A merge point can be placed at the loop exit, allowing these states to merge into a single state More info in our RTSS 2006 paper. Implemented in our tool “SWEET”

Dagstuhl Seminar on Resource Bound Analysis 22

Approach 3: The “Census” Method

Origin: MDH (Lisper 2003, Ermedahl et. al. 2007, Bygde et. al. 2008) Also Dortmund (Lokuciejewski et. al. 2009) Idea: for a given program point, the number of states provides an upper bound to the number of executions provided the program terminates (Each iteration must encounter a new state: if not, the computation will loop indefinitely.)

Dagstuhl Seminar on Resource Bound Analysis 23

The Census Method (II)

The method can be directly used to bound the # of loop iterations Use the result of a value analysis in some point in the loop (e.g., the loop header). The abstract state will represent (at least) all concrete states. Thus, the # of concrete states represented will bound the # of iterations Yields a very general scheme for loop bounds analysis. The abstract domain can be varied to give different tradeoffs between precision and scalability. A method to count the # of represented concrete states is required Pros: general, conceptually simple, tradeoff scalability/precision, can capture dependencies in nested loops, and give parametric bounds Cons: risk of imprecision if used naïvely

Dagstuhl Seminar on Resource Bound Analysis 24

Example

for i = 1 to 100 do for j = i to 100 do loop-body

1 i 1 100 j 100

#loop-body <= 5050 In this example we use a polyhedral abstract domain (Halbwachs 1978) for the value analysis This is a relational domain, can thus capture the triangular loop dependency

Dagstuhl Seminar on Resource Bound Analysis 25

Parametric Loop Iteration Bounds

for i = 1 to n do for j = i to n do loop-body

1 n i 1 n j

#loop-body <= n*(n+1)/2 Use the polyhedral abstract domain with variables i, j, n Symbolic methods for counting the # of integer points in polyhedra exist Can be used to compute the parametric bound automatically

Dagstuhl Seminar on Resource Bound Analysis 26

Approach 4: WCET Squeezing

A method to improve an existing WCET bound obtained by IPET. Origin: TU Vienna (Knoop et. al. 2013) Observation: the WCET bound may be based on an infeasible path, due to untight flow constraints. If we can find out, then the path can be removed and the bound sharpened The ILP solution is an array of execution counters. It defines a set of paths Run a precise analysis method, like symbolic execution, on all paths to find whether they are feasible or not. If none is, then generate constraints that exclude them and run the IPET calculation anew Can be iterated if necessary

Dagstuhl Seminar on Resource Bound Analysis 27

WCET Squeezing

Pros:

• Appealing idea: use an expensive but precise analysis only where it

makes a difference

• Works for any IPET-based WCET bound
• Anytime algorithm, iterations can be stopped whenever suitable

Cons:

• Does not provide a full Control Flow Analysis

Dagstuhl Seminar on Resource Bound Analysis 28

Summing Up

CFA for WCET analysis: to constrain the # of times that different program fragments can execute Arithmetic constraints on execution counters in the IPET model Only code is analysed – standard program analysis frameworks can be used Hard problem (undecidable), nevertheless several methods and tools exist Key for usability of WCET analysis tools – hard and error-prone to derive the constraints manually!

Dagstuhl Seminar on Resource Bound Analysis 29