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 Annotations Program source Flow analysis Compiler WCET Calculation Value analysis estimate Low−level Object code HW timing model analysis 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: n0 i := 0 start i < n stop i := i+1 false n1 true n5 true false i < n−10 n2 B1 B2 n3 n4 Various refinements exist (like Jan’s Abstract Execution Graphs) Dagstuhl Seminar on Resource Bound Analysis 7
For each node n i (basic block) in the CFG, let t i be an upper local WCET bound for n i Define an execution counter x i for each n i : • Initialised to 0 • Incremented by 1 each time n i is executed • “Virtual variables”, not present in the code • Their final values characterise the execution path for a complete run max � x i t i 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 x i t i i 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: • x i ≥ 0 for all n i (counters must be non-negative) • Structural flow constraints (from CFG structure): – For each node � = start, stop, � input counters = � output counters – x i = 1 if n i is the start or stop node of the CFG • Semantic constraints : – Loop iteration bounds (capacity bounds): x i ≤ c – Infeasible paths (mutual exclusivity): x i + x j ≤ c – Relative bounds (often in nested loops): x i = c · x j 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
Recommend
More recommend
