7.2 WCET Verification at Machine Code Level
7.2.3 The ILP Verification Problem
The optimization problem is defined as the maximization of the objective function WCET, subject to a set of linear constraints. The variables of the problem are the node iteration variables, xk, which are defined in terms of the of edge iteration variables, dINki and dOUTkj .
Edge iteration variables correspond to the incoming (i) and outgoing (j) edges to/from a particular program label identifier k contained in the weak topological order hLab, i. These linear constraints are called flow conservation constraints. Additionally, a set of capacity constraints establish the upper bounds, bki and bkj, for the edge iteration variables.
xk= n X i=1 dIN ki = m X j=1 dOUT kj (7.3) dIN ki 6 bki and dOUTkj 6 bkj (7.4)
The objective function is a linear function corresponding to the number of node iterations on each label identifier k ∈ L, weighted by a set of constants, ck, which specify the execution
cost, measured in CPI, associated to every label identifier.
WCET =X
k∈L
ck·xk (7.5)
As opposed to similar approaches to WCET analysis, e.g. the combined approach AI+ILP presented in [142], the structure of our optimization problem is particular, in the sense that its solution always assigns integer values to all the variables. This allows us to omit integrality constrains, and furthermore opens the possibility of using linear programming duality in our verification approach. Henceforth, we use refer exclusively linear programming (LP) instead of integer linear program (ILP).
Here, our aim is to demonstrate that the above optimization model can be formally obtained using the theory of abstract interpretation. Note, however, that the WCET is not the result of an abstract fixpoint computation. Only the correctness of the LP formulation, which is a set of linear constraints, is expressed by a Galois connection. To this end, the possibility to parametrize the transition system hΣ, τi with different domains is of great importance. Let T the set of identifiers of program input-output transitions. Then, the flow conservation constraints of Def. (7.3) are a set of equations of type ℘(L 7→ ℘(T )). Therefore, a Galois connection (αL, γL) is established between the relational semantics, RL, and the
flow conservation constraints domain, CL:
h℘(L × T × L), ⊆i −−−−→←−←−−−−→− αL γL h℘(L 7→ ℘(T )), 6i (7.6) where αL(RL) ,{xk = Pni=1dINki | ∀xk ∈ L: dINk = {e 0 | ∃x l∈ L: hxl, e0, xki ∈RL}} ∪ {xk = Pmj=1dkjOUT | ∀xk∈ L: dOUTk = {e 0| ∃x l∈ L: hxk, e0, xli ∈RL}}
γL(CL) , {hxk, dout, xli | ∃s1 ∈CL, ∃dout ∈rhs(s1) : xk∈lhs(s1) ∧
∃s2 ∈CL, ∃din∈rhs(s2) : xl∈lhs(s2) ∧ dout≡din}
Having proved the correctness of the linear constraints generation process by means of a Galois connection and defining a formal verification of the linear problem based on dual the- ory, the next step is to encode these mathematical definitions directly into declarative code. The objective of our declarative implementation aims to establish a direct correspondence between formal definitions and functional definitions using the high-level syntax of Haskell. The desired level of abstraction is achieved by means of a proper domain specific language2
(DSL) that defines a linear (Program t) to be a composition of adirectionof the optimization function, anobjective function, a set ofvariables and a set ofconstraints. The abstract syntax
used to express the objective function and the constrains is defined by the datatype Expr. Expressions of the DSL are inductively defined either as constant values (Con) of some polymorphic typet, symbolic variables (Var), or abstract functions (App), which apply the binary operator denoted by P rimOp to the first element of a list of expressions ([Expr t]) and to the second element of the same list. The abstract functions of the DSL consist in the overloaded infix operators(+), (−)and (∗), in the abstract comparisons (>]),(6]) and (≡]) and, finally, in the abstract assignment(=]).
data Expr t = Con t | VarSym| AppP rimOp[Expr t ] typeP rimOp=String
typeSym =String
data Direction = Maximize | Minimize
data Program t = Program {direction:: Direction,objective:: (Expr t ,String),
variables:: [(Sym,String)],
constraints:: [(Expr t ,String)]}
Next, we describe how the formal definitions of the WCET linear program can be defined using the DSL. We start with definition (7.5) of the WCET objective function, which will be maximized by the simplex method. Given a set of labels l, the translation of this definition into the DSL is specified by the function maximize as the product of the cost vectors ck (of
type F low) and the the node variable vector xk, for each k-indexed label. Using the Haskell
notation of list comprehensions, the DSL objective function is given by:
maximize"wcet" $sum[c(k )∗ x(k ) | k ← l ]
The next step is the translation of the flow conservation constrains defined in (7.3) and the capacity constraints defined in (7.4). In the former case, we are interested in the translation of the abstraction αL(RL) of Def. (7.6) into Haskell. To this end, define two sets of constraints
using the functionsubject to: the first for the set of incoming edges and the second for the set
of outgoing edges to/from a given node. Besides the set of labelsl, also a set of transitions t is available from the monadic context of the DSL.
2
subject to"incoming" [x(k )=]sum[d(j ) | j ← t ,n(k )>>]e(j )] | k ← l ]
subject to"outgoing" [x(k )=]sum[d(j ) | j ← t ,n(k )<<]e(j )] | k ← l ]
The auxiliary functions <<] and >>] respectively determine if the label given by e(j ) is an
"incoming" edge or a "outgoing" edge of a node. Again, the DSL allows us to define these constraints in a purely declarative way as a direct translation of the mathematical definition. Finally, the capacity constraints defined in (7.4) are translated with another invocation of the functionsubject to, where a list of j-indexed input-output transition identifiers is taken
from the monadic context.
subject to"bounds" [d(j )6]b (j ) | j ← t ]
By definition, the variable vector x and the edge vector d must be indexed by unique
identifiers. On the other hand, the cost vectorcand the bounds vectorbare vectors indexed
by the number of label identifiers (l) and by the number of transition relations (t). Hence, the variables of the linear problem must be instantiated in the monadic context in such a way that they can be accessed through the same indexes l and t. For this purpose, the functionvar is used in theState monadic context ofProgram:
x←var "x" l
d←var "d" t
All the required vectors, i.e. the execution costs, the loop iteration bounds and the node and edge names, have the type (P aram i), wherei is an index. Since all constraints are specified by means of expressions of type (Expr t), we define the parameters of the WCET linear programming specification by instantiating the type variable t with the inductive datatype LPVal. The constructor ofNode,Costand Boundconstants isVal, whereas the constructor
Edge isPair.
data LPVal = ValInt| Pair (Int,Int) typeP aram= Expr LPVal
typeP aram i = i →P aram
The complete DSLspecification of the WCET linear program in given by:
typeCost,Bound,N ode,Edge=P aram String
specification (l :: [String]) (t :: [String]) (c::Cost) (b ::Bound) (n::N ode) (e::Edge) = do
x←var "x" l
d←var "d" t
maximize"wcet" $sum[c(k )∗ x(k ) | k ← l ]
subject to"incoming" [x(k )=]sum[d(j ) | j ← t ,n(k )>>]e(j )] | k ← l ]
subject to"outgoing" [x(k )=]sum[d(j ) | j ← t ,n(k )<<]e(j )] | k ← l ]
subject to"bounds" [d(j )6]b (j ) | j ← t ]
After specifying the WCET using the linear programming DSL, a further step is required to invoke the GLPK [53] simplex solver. The reason for this is that GLPK is accessible from Haskell through the GLPK bindings library GLPK-hs. However, this requires only a
transformation between the abstract syntax of the DSL into the abstract syntax of GLPK- hs. Afterwards, the system call to the native GLPK simplex solver can be performed. The reader is referred to the Haskell prototype for the complete DSL definition.