Loop bound analysis is the general problem of determining the number of times each loop in a program can execute. In general, this cannot be solved as loop bound analysis can be trivially equated to the halting problem. However, real-time systems are typically not the general case; as real-time systems are programmed with time constraints in mind, additional restric- tions on the programming techniques used can be applied [82] such that it is possible to determine if the program halts. By extension, this means that upper bounds can be placed on the number of times each loop executes.
Loop bound analysis is a critical part of determining the worst case exe- cution time of a program. As the previous section on caches demonstrated, a large amount of die area is given to cache. Instruction cache is primarily to speed the execution of loops [55]. While certain loops are trivial to place
bounds on, for example those which have a fixed number of iterations, the conditions for a loop can also be complex and depend on multiple variables. While techniques such as IPET (as mentioned in Section 2.2.3) provide bounds on loops by definition, such techniques either do not produce tight bounds or do not scale to large programs. This is because IPET techniques that do not perform loop bound analysis can either enumerate every possible path through the loop or make pessimistic assumptions about variables. In the former case the problem is intractable due to the difficulty of expressing loop invariants as ILP problems [111]; in the latter case bounds are not tight.
2.4.1 Value Analysis and Abstract Interpretation
In order to circumvent the problems of an exhaustive search via IPET, it is necessary to use more intelligent methods. As variables can be used in loops, Value Analysis plays a key role in Loop Bound analysis. Value analysis refers to techniques that attempt to predict the possible values that variables can take within the program. The benefits of value analysis are considered by Ermedahl and Gustafsson [43], who show how a value analysis can provide information which both enhances the precision of the WCET estimate and eliminates the need for some annotations. The first issue they address is eliminating false paths through the program, by using conditional statements to force conditions on the dependent variables for the remainder of the program. For example, if a program branch is executed conditional on x > 20, x should be assumed to be greater than 20 until the variable leaves scope. By extension this method can also apply to finding loop bounds by expressing the unrolling of the loop and expressing it as a series of if statements. Providing that the loop terminates, this analysis will terminate and find the bound on the loop because the conditions on the loop variable will continually tighten.
Unfortunately, performing Ermedahl and Gustafsson’s analysis [43] in this manner produce a large number of states to evaluate. For this reason, they discuss the necessity of merging states, but note a distinction between states. Some states may be redundant and not contribute to the analysis; these states can be merged with no penalty. States which are not redundant may be merged as well, but in this case there is a penalty in the precision of the WCET estimate. This leads to using techniques to reduce the number
of states to consider.
Of the current approaches to WCET estimation that implement value analysis, abstract interpretation is the favoured method ([100, 112, 47]). A reason for this is given in the analysis of the Coldfire processor by Ferdi- nand et al. [47]: values of program variables are typically unknown, but it may be possible to calculate intervals which the value is guaranteed within. This corresponds well to abstract interpretation, as the intervals are easily thought of as abstract states. Further, merging is easily thought of as a merging operator by simply picking an interval encompassing the two ab- stract states to be merged. Operations can then be defined on intervals which make sense; for instance, two intervals can be added together to find the interval which the result will lie within. The only issue that Ferdinand et al. identify with this approach is that these operations become undefined if the interval contains overflow values, because it is unknown if an overflow will actually happen in the concrete representation of the program.
Abstract Interpretation applied to Value Analysis is very close to the purest form of abstract interpretation, as defined by Cousot and Cousot [36]. In this case the process is iterative; information about variables is propagated through the statements of the program via a series of rules. The rules are not equivalent to executing the program; instead information is extracted about the possible values of a variable at each point. Typically, this is used to first compute a lower bound, and then an upper bound. After this step, abstract interpretation has found a fixed point. However, the information in the first fixed point found may not be adequate; for example, an upper bound may have been calculated as infinity. This can be corrected by iterating the process, using information from the previous iterations. Such information can be used to improve the tightness of subsequent fixed points, with the aim of removing overly large amounts of pessimism.
The information propagated in abstract interpretation can come from a variety of sources. An important first source is the initial assignment; in the case of a variable from an outside source, the range of values that the variable may take must be known. Further to this, statements inside the program can reveal information about possible values in certain segments of the program. For example, if a basic block is reached by traversing the conditional statement if x > 0, it can be inferred that for the duration of that block x is a positive number.
Many tools available depend on the use of additional information from the user, supplied in the form of annotations [82, 61, 100]. These annotations are used to provide information which is difficult to infer otherwise, such as the values that variables will take or loop bounds. Unfortunately, as annotations are supplied by the user, they are susceptible to human error, a point made by Prantl et al. [81]. Prantl et al. argue that due to this potential error it is necessary to verify annotations, in a similar way that the program itself may be tested. This is accomplished by exploiting the fact that it is possible to determine if a program is guaranteed to terminate within a given time. Hence if a WCET bound is given which involves the use of annotations, it is possible to verify it. Prantl et al. acknowledge one core failing of this approach: it is computationally expensive. To mitigate this, Prantl et al. state that the program analysis should be simplified first by another method, such as abstract interpretation.
However, many implementations of value (and by extension, loop bound analysis) do not verify annotations, and assume correctness. This can be seen in comparisons of such tools [112], where variations of the phrase “once the source code has been annotated” feature heavily, but with no mention of verification of such annotations, or mention of features to detect errors in annotations. Attempts have been made on the verification of annotations; notably Chapman et al. [27] intended to use the submit annotations in SPARK Ada to a theorem prover to check that annotations were correct, although this work was not completed. Also of note is that in benchmarks where some source code is not present, for example in the case of a shared library, the majority of tools compared in [112] exhibit critical problems, and leads to significant loss of tightness in others.
2.4.2 Summary
Loop bound analysis is a critical part of finding the worst case path through a program, and hence critical to WCET estimation. By extension, this means that Value Analysis is also critical. Currently, a weakness of common techniques is the use of unverified annotations. As unverified annotations may introduce incorrect information to the analysis, there is an argument that it would be desirable to reduce the dependence on such annotations.
An examination of current techniques in the context of information the- ory is presented in Chapter 3.4.2. Loop bound analysis itself will then be
revisited in Chapter 5.