Scenario-Aware Program Specialization for Timing Predictability Scenario-Aware Program Specialization for Timing Predictability

3.4.1 Specialization-Point Refinement. SP refinement is based on the possibility of specializing call-context sensitively. Refining a specialization point $SP = (CS, M)$ is done in two steps. First, a subset of call sites $CS1 \subseteq CS$ that share a set $M1$ of parameter–value pairs is gathered. The latter must meet one important condition, that is . Note that value $v$ for parameter $p$ has to be statically derivable. Next, a new specialization point $SP1 = (CS1, M^{\prime })$ is created, where $M^{\prime } = M \cup M1$. The original SP is updated as follows: $SP = (CS \setminus CS1, M)$.

For example, Figure 7 shows the two call sites from main to write_colormap of cjpeg_wrbmp. Note that three of the four parameters passed to all calls to write_colormap are constant values. Using SP refinement it is possible to define a smaller scenario for cjpeg_wrbmp than the one shown in Figure 5(a). The resulting scenario consists of the parameters output_height and actual_number_of_colors. Figure 8(a) shows the SP created for the call sites shown in Figure 7 and the size-reduced scenario. Figure 8(b) shows the SP after refinement, which is identical to the one created based on the full scenario (cf. Figure 6). The call sites after specialization using the refined SP are shown on the right of Figure 7. In this example, refinement does not create a new SP, since all call sites of the existing SP can be refined with the same set of parameter–value pairs.

3.4.2 Specialization-Point Propagation. Another optimization is SP propagation, which is call-context sensitive as well. In contrast to refinement, existing SPs remain unchanged and are used to create new ones. More precisely, let $f_{SP}$ be a function that was specialized for specialization point $SP = (CS, M)$. Now assume, that $f_{SP}$ contains a call site to function $g$. Further, assume that $g$ cannot be specialized for any of the user-provided scenario instances. Instead, assume that one or more parameters passed from $f_{SP}$ to $g$ can be statically derived as a result of specializing $f$ with $SP$. In that case, SP propagation can be used to allow specialization of $cs$ for the statically derivable parameters. Hence, a new specialization point $SP2 = (\lbrace cs\rbrace , M2)$ is created, with $M2 = \lbrace (p_i, v_i) : v_i \: \: \mathrm{statically \: derivable} \rbrace$. Therefore, SP propagation can be loosely described as specialization-aware context-sensitive constant propagation.

For example, assume that the function write_colormap from cjpeg_wrbmp calls another function funcA with parameter map_colors: funcA(map_colors). Although this function was not considered during scenario extraction as performed in Section 3.2, using SP propagation it is possible to specialize it, which yields a new SP as shown in Figure 9.

As mentioned in Section 3.2, we propose to extract scenario parameters based on functions close to CG root. Combined with SP refinement and propagation it is possible to extend the coverage of scenario-aware program specialization throughout the CG. This allows automatically extracted scenarios to perform similar to manually extracted scenarios, as shown in Section 5.2. Moreover, input required from a user can be kept small and rather simple.

3.4.3 Selective Multi-Clone Specialization. Automatically applying optimizations like SP refinement or propagation may have a negative effect on predictability. It is possible that different call sites to a single function are specialized for different SPs as a result of refinement or propagation. For example, refining two call sites to a function funcB for different constant parameter values requires two different clones. In addition, funcB may contain a statically unboundable loop. In that case, each clone of funcB would increase the number of unbounded loops and therefore decrease predictability. Since the goal of the presented optimizations is to increase predictability and simplify scenario creation, it is necessary to prevent any negative effects. Thus, we use a heuristic called selective multi-clone specialization to prevent the creation of multiple clones that may reduce predictability. Multi scenario-instance specialization is not considered, since it is user controlled and targeted at handling dynamic behavior at run time.

Figure 10(a) shows the algorithm that implements our heuristic. The workflow is as follows. For each function f with multiple clones, the set of call sites to f is collected. The actual heuristic is implemented in CheckCallSite, which is shown in Figure 10(b). This function determines if a call site should be removed from the associated SP and therefore not be specialized. More specifically, it makes sure that each loop part of the corresponding callee can be statically bound. To that end, it calls BoundForSP that uses the additional value information provided by specializing for SP to derive safe loop bounds.

3.5.1 Multi Scenario-Instance Specialization. It is possible that a system requires multiple scenario instances that are switched at run time. For example, an embedded system that captures and processes images may work with different camera resolutions. In that case, any algorithm that depends on the size of the captured image can be specialized for multiple scenario instances—one for each resolution. More specifically, each call site to such an algorithm can be specialized for two or more scenario instances. Since scenario instances cause creation of SPs, each call site is associated with multiple SPs. Specializing a call site for multiple SPs yields multiple call sites instead of one. Hence, a mechanism is required that allows selection of the appropriate call site at run time, which is based on those scenario parameters that vary between different instances.

To ensure functional correctness, a call site associated with multiple SPs either has to be specialized for all SPs or none. Otherwise, it is possible that a scenario instance is active at run time, for which specialization was not performed. To handle run-time behavior, we propose scenario guards to be generated around each call site that is part of multiple SPs. Scenario guards can be implemented using conditional statements available in any modern programming language. More specifically, for a specialization point $SP = (CS, M)$ and a call site $cs \in CS$, a guard checks that $a_p == v$ holds for all parameter–value pairs $(p, v)$ and the corresponding call argument $a_p$. That way, it is guaranteed at run time that the correct version of a function is used for each active scenario.

Note that we assume that scenario instances are switched implicitly at run time. For example, an embedded system that captures and processes images may switch between scenario instances by resizing a captured image or changing camera resolution at run time. Therefore, it is not necessary to manually adopt the transformed program to perform scenario-instance switches, since the currently active instance is automatically detected using scenario guards. Our current model of multi scenario-instance specialization does not support asynchronous scenario-instance changes that may lead to a change during execution of a specialized function.

5.1.1 Experimental Methodology. To compare our approach with the work of Barany et al., we used the complete Mrdalen benchmark suite and the fixed-point version of the DSPStone benchmark. For comparison with Kafshdooz et al., we used the same subsets of Mrdalen and MiBench as the related work. In both cases, the relative WCET, as reported by the related work,² was used for comparison. We chose optimization level O1 for comparison with Barany et al. and optimization level O3 for comparison with Kafshdooz et al.

First, we used aiT to calculate a reference WCET. Then, we used manually extracted scenarios to transform each benchmark without any SP optimizations. We chose this approach as manually extracted scenarios without SP optimizations give an experienced user the most flexibility and control. Next, aiT was used to determine a WCET estimate for the transformed benchmarks. Finally, a relative WCET was calculated as discussed in the following section.

5.1.2 Results and Discussion. All figures in this section share the same semantics and we use Figure 12 as an example to discuss it. On the y-axis, the relative WCET ($WCET_{rel}$) of each bench- mark is shown, with $WCET_{rel} = \frac{WCET_{trans}}{WCET_{orig}} \cdot 100.$ $WCET_{trans}$ denotes the WCET of the benchmark transformed with our framework. $WCET_{orig}$ is the WCET of the original, unchanged benchmark. Due to space restrictions, we only show results for those benchmarks where $WCET_{trans} \ne WCET_{orig}$. As mentioned previously, both $WCET_{orig}$ and $WCET_{trans}$ denote the WCET estimate returned by aiT. The gray horizontal line in Figure 12 marks the reference WCET of the original benchmarks. The dark gray bars show the relative WCET of the benchmarks after applying our methodology, while the light gray bars represent the results of the corresponding related work. In case of Figure 12, these are the results from Kafshdooz et al.

As already mentioned, Figure 12 shows the results for comparison with the work of Kafshdooz et al. First, we achieve an average reduction of WCET of about $17\%$, which is slightly lower than that achieved by the related work (about $20\%$). This is caused by the fact that there was no opportunity for scenario extraction for most of these benchmarks. Unfortunately, many benchmarks have this property, since system parameters are often hard-coded constants instead of variables. On the other hand, we extracted a scenario for compress, crc, ludcmp, minver, and susan. For these benchmarks, the average reduction of WCET is about $45\%$ and in almost all cases, except for minver, we achieve significantly better reductions than the related work. The large reduction in case of susan is caused by aiT being able to precisely bound all loops that are on the WCEP. This is due to both specialization and the transformation presented in Section 4.2. In addition, the compiler can eliminate dead code more efficiently which also improves the WCET estimate returned by aiT. Finally, note that it is possible to combine our approach with the one proposed by Kafshdooz et al. to further enhance predictability.

Figure 13(a) shows the results of this work and the work of Barany et al. for the fixed-point version of the DSPStone benchmarks. In contrast to the related work, most benchmarks are unchanged by our approach, which is due to the simplicity of these benchmarks. Most benchmarks consist of only one or two functions and, more importantly, there are only a few system parameters, almost all of which are hard-coded constants. Hence, there was no opportunity for scenario extraction for any of those benchmarks. Thus, the few benchmarks with large WCET reductions, namely fir2dim, matrix1, and matrix2, benefit from the transformation to preserve binary-level loop bounds. More specifically, in case of these benchmarks aiT was able to precisely bound all loops thanks to the transformation applied by our framework. In contrast, aiT was unable to bound any loop of the original, unchanged benchmarks. These rather extreme reductions can be partially attributed to the fact that aiT uses a default loop bound as fallback. This leads to an average reduction of WCET, as reported by aiT, of about $26\%$, which is slightly better than the related work ($23\%$). In addition, WCET was never increased in contrast to the work of Barany et al. (cf. fir2dim).

Figure 13(b) shows results for the Mrdalen benchmark suite of Barany et al. and this work. For some benchmarks, for example compress, there is no result from the related work, since these benchmarks were not part of their evaluation. We were able to extract a scenario for compress, crc, duff, edn, expint, fdct, fft1, ludcmp, minver, and ud. Due to scenario-aware specialization, we achieved an average reduction of WCET of about $35\%$ for these benchmarks. In addition, reductions for all these benchmarks, except expint and minver, were significantly better compared to related work. Moreover, predictability was never decreased, in contrast to the related work where the WCET of crc and whet is increased significantly. In case of fft1, due to specialization and the transformation to preserve binary-level loop bounds, aiT was able to bound all loops part of the WCEP. In addition, the compiler was much more effective during optimization, especially dead-code elimination. The WCET improvements of all other benchmarks are solely caused by the transition to preserve binary-level loop bounds. Overall, we achieve an average reduction of WCET of about $20\%$, which is slightly better than the related work (about $15\%$). Again note, that the approach presented in this work and the work by Barany et al. could be combined to achieve even better improvements.

5.2.1 Experimental Methodology. First, each of the original benchmarks was analyzed by aiT to calculate a reference WCET for each benchmark. Then, our framework was executed to transform each benchmark according to the following configurations. First, only scenario-aware procedure cloning without any SP optimizations was performed (Scenario only) and then specialization with all SP optimizations (SP optimizations).

Next, aiT was used to calculate the WCET of each benchmark for each of those configurations. More specifically, all versions of the benchmarks (original, scenarios only, and SP optimizations) were compiled with compiler-optimization levels O1 and Os. For manual as well as automated scenario extraction, we created a single scenario instance where applicable. As mentioned previously, benchmarks used in timing analysis research, such as TACLeBench or Mrdalen, are often optimized for WCET analysis. Thus, most of these benchmarks already have a good timing predictability w.r.t. WCET analysis. Therefore, we created scenarios for 16 out of 56 benchmarks and a single instance for each scenario during manual scenario extraction. Automatic scenario extraction was performed with a max_dist of 1 and yielded 16 scenarios and we manually created an instance for each.

5.2.2 Manual Scenario Extraction. Manual scenario extraction was performed similar to the approach for automatic extraction as described in Section 3.2. More specifically, to extract scenario parameters for a given benchmark, we first inspect all functions called from the main function. Next, we move along the different paths through the CG that start with those initially identified call sites. We scan each function for parameter uses and determine if knowing this parameter at analysis time may have a positive impact on timing predictability. A parameter is determined to possibly improve timing predictability if its knowledge makes it feasible to statically derive the value of a loop bound or boolean expression. A developer with proper understanding of the source code at hand is much more capable at obtaining loop bounds or boolean expressions than the heuristics presented in Section 3.2. Hence, this last step is an important difference to automatic extraction. Another difference is that we do not use something like max_dist when manually extracting scenario parameters. In addition, a developer may recognize or know that one or more parameters are passed down along paths of the CG and select this parameter if it may improve predictability in any of the functions along that path. Thus, when manually extracting scenarios, we may do what some of the SP optimizations, intended for automated scenario extraction, do.

5.2.3 Results and Discussion. In this section, we present and discuss the results of our evaluation to compare the effectiveness of automated scenario extraction with manual scenario extraction. All figures in this section have the same semantics, which we discuss in the following using Figure 14(a). The line parallel to the x-axis denotes the reference WCET of the original benchmarks. The bar plots show the WCET of the transformed benchmarks and are labeled with their exact value rounded to one decimal place. The dark-gray bars represent the WCET for manual scenario extraction, while the light-gray bars represent the WCET for automated scenario extraction.

Figure 14(a) shows the relative WCET, that results from specialization without SP optimizations, for benchmarks compiled with optimization level O1. The WCET of cjpeg_wrbmp is reduced by about 46% and there is no difference between manually and automatically extracted scenarios. The scenario shown in Figure 5(a) was used in both cases. Thus, for cjpeg_wrbmp, our automated scenario extraction yielded the same scenario parameters as manual extraction. In addition, aiT was able to detect one of four loop bounds for the original benchmark. In contrast, all loop bounds were detected for the transformed benchmark. The bound detected in both the original and transformed benchmark was more precise in case of the transformed benchmark. Also, the parameter cMap part of the scenario for cjpeg_wrbmp improved infeasible paths detection. The results for the benchmarks fir2dim, gsm_enc, and ludcmp can all be attributed to an increased number of detected loop bounds. In case of fir2dim, no scenarios were extracted. Hence, the improved WCET is caused by the transformation to preserve loop bounds at the binary level (c.f. Section 4.2). The manually extracted scenario for gsm_enc contains a single parameter, while automatic extraction was unable to find suitable parameters. For ludcmp, both manual and automatic extraction yielded a scenario. Although the automatically extracted scenario is a subset of the manually extracted one, the respective WCETs are quite close. In case of h264_dec, the extracted scenarios differ most. The scenario created manually contains 11 parameters and the automatically extracted contains three. These three parameters are shared by both scenarios. The improvement is quite large, for manual extraction about 94% and about 75% for automatic extraction. In case of manual extraction, aiT was able to derive all loop bounds for the transformed benchmark, while only two of seven bounds were detected for the original benchmark. On the other hand, aiT was able to bound one more loop compared to the original benchmark for automatic scenario extraction.

Figure 14(b) shows the relative WCET, that results from specialization with SP optimizations, for benchmarks compiled with optimization level O1. SP optimizations introduced a small increase of WCET of up to $0.5\%$ for the adpcm benchmarks and one of $1.3\%$ for gsm_dec. The WCET of gsm_enc was slightly increased compared to the benchmarks without SP optimizations, while it was still reduced by about $74\%$ compared to the original benchmark. On the other hand, many results improved, especially for automatic scenario extraction. In case of audiobeam, ludcmp, and mpeg2, the results for automatically extracted scenarios now are the same as for manually extracted scenarios. In addition, the results of g723_enc and minver do not significantly differ between automatically and manually extracted scenarios. This is in contrast with the results without SP optimizations: automatically extracted scenarios either performed worse than manually extracted scenarios for these benchmarks or did not improve WCET at all. Compared to the results from unoptimized SPs, results for manually extracted scenarios could be improved as well. The WCET of g723_enc was further reduced, while improving the WCET of mpeg2 was only possible with SP optimizations.

Figure 15(a) shows the relative WCET for benchmarks compiled with optimization level Os. SP optimizations were not performed. There are several large improvements of predictability in terms of WCET. These can be partially attributed to the fact that aiT was instructed to use a benchmark-wide default loop bound for unbounded loops. On the other hand, the transformations performed by our framework lead to an improvement even if aiT was able to bound all loops. For example, the WCET of bsort was reduced by about 44% due to the applied transformations. In that case, aiT derived all loop bounds for the transformed and the original benchmark. In addition, these bounds were derived with the same accuracy. Applying scenario-aware program specialization improves the ability of static analyses to determine, for example, value information or feasible paths information. Compiler optimizations like dead-code elimination profit from these transformations as well. In general, compilers can optimize more effectively due the additionally available value information provided by scenario-aware program specialization.

Figure 15(b) shows the relative WCET for benchmarks compiled with optimization level Os and SP optimizations. For adpcm_enc, WCET was slightly increased by $0.2\%$ independent of the used scenario extraction method. In case of minver, the WCET was increased by $1.5\%$ for automatically extracted scenarios only. On the other hand, results were improved significantly for several other benchmarks. The results for automatically extracted scenarios equal those of manual extraction for audiobeam and ludcmp. Moreover, there is no significant difference between results from manual and automatic scenario extraction in case of g723_enc. The improvements of WCET for mpeg2 and rijndael_dec were enabled by SP optimizations.

5.3.1 Experimental Methodology. To evaluate the impact of max_dist on timing predictability, we performed automated extraction for different values of max_dist with $1 \le max\_dist \le max_{cg\_depth}$ and $max_{cg\_depth} = \max (\lbrace cg\_depth(b) | b \in benchmarks\rbrace)$. The evaluation to compare manual and automated scenario extraction was conducted exactly as described in Section 5.2. For each benchmark and a certain value $n$ of max_dist, we only included the corresponding scenarios in our evaluation if there was no value $n^{\prime } \lt n$ that yielded the exact same scenario.

5.3.2 Results and Discussion. First, for values $n$ of max_dist with $n \ge 6,$ no new scenarios were extracted for any benchmark. More importantly, there was no significant change in timing predictability w.r.t. WCET analysis for any possible value of $max\_dist \le 5$ compared to $max\_dist = 2$. With all SP optimizations enabled, there was no difference at all and only a small difference when disabling all SP optimizations. In case of optimization level O1, the relative WCET of g723_enc was improved to $98.4\%$ (previously $100\%$) for $max\_dist \ge 2$ and is the same as for manual scenario extraction. Similarly, for optimization level Os, only the relative WCET of g723_enc was improved to $97.9\%$ for $max\_dist \ge 2$, which is closer to manual scenario extraction.

There are several reasons why increasing max_dist did not help for almost all benchmarks whereas SP optimizations did. First, the algorithm shown in Figure 2(a) is a heuristic that returns a subset of parameters that has the largest possible score and there exists no set, which has the same score and a lower cardinality. Thus, the automatically extracted scenario may be missing parameters because the heuristic prefers smaller subsets, which is done to keep the complexity of manual scenario-instance creation as low as possible. Moreover, the heuristic chooses one of possibly many sets with the same cardinality and the highest score. Hence, it is possible that a different subset has a greater impact on predictability. More importantly, to calculate the score of a subset, the number of influenced control-flow statements is derived, which is done by a very simple static analysis. In contrast, an experienced developer can perform much more complex analyses to determine the analyzability of expressions or statements. In conclusion, it is most likely that the simplicity of the heuristic, which is intentional since the number of subsets to be inspected can become quite large, is the reason why increasing max_dist does not further improve WCET.

Again, the purpose of scenario extraction is to support a user during scenario extraction without increasing complexity by returning large sets of scenario-parameter candidates. Moreover, automatic scenario extraction is intended to be used with SP optimizations, especially SP propagation, to maximize the effect of specialization throughout the entire application. Finally, SP optimizations indeed close the gap between manual and automatic scenario extraction in most cases, for example, audiobeam and duff for optimization level O1 or g723_enc for Os and hence, work as intended.

5.4.1 Experimental Methodology. To investigate the effect of multi scenario-instance specialization compared to single scenario instances, we used the benchmarks cjpeg_wrbmp and h264_dec. These are among the best performing benchmarks for single scenario instances. Thus, they are best suited to show the effect of specialization for multiple scenario instances on the improvement of WCET compared to single-instance specialization. For both benchmarks, the same manually extracted scenarios as in the previous section were used. In contrast to real-world software, benchmarks often contain values, that are unknown in general, as hard-coded constants. For example, as local or global variables with const qualifier or preprocessor defines. Thus, to be able to specialize these benchmarks for multiple scenario instances, we replaced some hard-coded constants with variables.

Four scenario instances with different parameter–value maps were created and six versions of each benchmark. More specifically, the original benchmark corresponds to the version none. We also created a version all, that was specialized for all four scenario instances. Hence, all functions that were specialized were cloned four times and the corresponding call sites were guarded using scenario guards. In addition, we created a single-instance version of each benchmark for each scenario instance, named $s_i, i \in \lbrace 0,1,2,3\rbrace$. To evaluate the impact of multi-instance specialization on timing predictability, we need to verify that the following equation holds:

5.4.2 Results and Discussion. To check against the metric shown in Equation (1), we calculate the ratios presented in Figure 16 for both benchmarks and optimization levels. Note that Figure 16 shows all absolute WCETs, used to calculate these ratios. The first two rows correspond to cjpeg_wrbmp and the following rows to h264_dec, while all ratios are rounded to two decimal places. Independent of optimization level, the ratio $\frac{WCET_{all}}{WCET_{s0}}$ indicates no significant loss of predictability w.r.t. WCET. Also, WCET of the multi scenario-instance variant could be improved significantly compared to the original benchmark (none), as shown by ratio $\frac{WCET_{all}}{WCET_{none}}$. Again, aiT was able to precisely bound all loops for all specialized variants, while only a single bound was derived for the original benchmark. Of course, specializing for multiple scenario instances may increase binary size significantly. As the latter is an important property for many embedded systems, the last column shows the ratio $\frac{size_{all}}{size_{none}}$. There is no significant overhead in binary size for any used optimization level or benchmark. This can be explained in a similar way as the improvement of WCET: additionally available value and data-flow information have a significant effect on the ability of the compiler to apply optimizations. For example, the cMap parameter of write_colormap (cf. Figure 4) allows GCC to classify a significant part of this function as unreachable. A similar effect is seen in the specialization of parameter map_entry_size of the same function.

5.5.1 Experimental Methodology. We used information about the image sizes and the predictability-relevant parameters of the CNN model for manual scenario creation. Important model parameters are input/output dimensions, kernel dimensions, number of channels, and stride. Since the application contains a large set of functions and has a complex CG, we used specialization with all SP optimizations. Then, we used aiT to calculate a WCET estimate for the original as well as the specialized benchmark.

5.5.2 Results and Discussion. Figure 17 shows the results of our case study. In addition to relative and absolute WCET, it shows the number of unbounded loops for each version of the application. Furthermore, for those loops, aiT was able to bound in both versions, it shows the number of bounds that were more precise.

WCET was reduced by about $7.5\%$. The number of loops aiT was unable to bound was reduced by 23 for the specialized application. In addition, precision of loop bound analysis was improved for 8 loops. Hence, predictability w.r.t. WCET and loop bound analysis was improved significantly compared to the original version of the application.