instructions. Code size can further be broken down into individual code segments, files, or functions.
Many factors affect power consumption. Since most of these factors are hardware related, power consumption is not always a concern for software developers. However, studies have shown that memory accesses usually consume slightly more power than ALU operations. This has an even larger effect in multimedia and signal processing applications that handle large data arrays in nested loops. Power consumption will require actual hardware to be measured.
Often referred to as the time it takes to complete the process of compiling and linking the entire software system, the build time depends on such factors as the application code size, host machine and network speed, license checkout type (floating vs. node-locked), as well as the number of compiler invocations and compiler options. We have seen that interfile optimization is one way to decrease built times. As well, there is usually a slight tradeoff between using more intense compiler optimizations and obtaining faster build times. Build times are usually measured by external utilities when the measurement method is not built into the compilation tools.
Each criterion was weighted based on its importance. For example, if execution speed is the most important, we could assign it an importance factor of 0.45, where each factor would be a percentage. The other three criteria factors would add up to exactly 0.55. For the test case, it was assumed that application code space was the most important criterion with a 0.75 importance factor, execution speed the second-most with a 0.25 importance factor, and power consumption and build time both had an importance factor of zero.
Optimization metric sets Mn = {an, bn, cn, dn} were defined by applying any combination of a set S (to be defined shortly) of compiler options on an application, where:
a = measurement of the most important criterion b = measurement of the second-most important criterion c = measurement of the third-most important criterion d = measurement of the least important criterion n = the nth combination of a set of options S
(to be defined shortly)
This list should not be considered complete by any means. It should also be noted that there are a variety of other criteria to consider for the overall optimization process (a superset of finding optimal compiler options), but these four are usually the most important criteria that can be influenced by the use of compiler options alone.
For build time, it was assumed that the host machine and network speeds, as well as the license checkout times, are constant.
Typically, the goals should be analyzed before developing the application, but this rarely happens. Once code has been developed, proven in terms of accuracy and correctness, and hand-optimized to be targeted to the particular platform, the process of testing compiler options can begin.
For the presented test case using this methodology, the same simulation tools were used (except that time simulation was done using an ARM7-based Atmel microcontroller [ 3] running at 40 MHz) and the test application was a slightly modified version of the Dhrystone Benchmark 2. 1 [ 14] for C. Dhrystone is a popular benchmarking program used to compare the performance of code generated with different compilers.
Dhrystone uses no floating-point and has a large focus on string handling. It is a good test program for the methodology since it can be heavily influenced by compiler options. The only modification made to the source code of Dhrystone 2. 1 was to fix the number of runs at 60,000. Also, a breakpoint was placed on the last line of main. The modification and breakpoint were done so that the entire application from start to finish could be timed consistently with the profiler. Otherwise, Dhrystone waits for the user to input the number of runs (which will always take a variable amount of time) and ultimately never ends (as is the case for most embedded applications).
All of the possible compiler options were studied and added to a preliminary test list if there was a possibility that the option could have had an effect on any of the criteria in question. For example, some compilers have options that suppress certain warnings or error messages. Using these options should not have any affect on the criteria, so were not added to the test list. The combinations that do not work together were known ahead of time. For example, typically only one level of general optimization can be accepted per compilation.
To create S, every one of the options from the test list was individually applied in combination with the lowest level of general optimization (-O0 in this case) and any option that was used by default (-Ospace in this case) when the application was compiled. An option was added to S if any element from the resulting metric set Mn was less than the corresponding element of the metric set Mn created by compiling the application with only -O0 (the lowest general level of optimization) and -Ospace (the only default option). Criteria whose importance factors were zero were completely ignored. In this case compiling the application with only -O0 gave a code size of 95,200 bytes and an execution speed of 10.17196830 seconds (for 60,0000 runs of Dhrystone 2. 1, as previously mentioned).
If an option depended on another option in order to be valid when creating S, both options for that case were used (see --thumb below in Table 5). The order of individual options tested should not
Compiler Option (elements of S)
--apcs=interwork --apcs=interwork/ropi —bss_threshold=0 -O1 -O2 -O3 -Otime --split_sections
--thumb —apcs=interwork*
Resulting Mn{code sizen , execution timen , NA, NA}
By Applying Individual Option
{93,664, 9.86574647, NA, NA}
{93,664, 9.86574647, NA, NA}
{95,144, 10.17196037, NA, NA}
{94,644, 9.08366435, NA, NA}
{94,472, 8.64248447, NA, NA}
{97,368, 8.64251822, NA, NA}
{95,400, 10.12394656, NA, NA}
{95,184, 10.17196668, NA, NA}
{92,632, 7.71468278, NA, NA}
*--apcs=interworking must be enabled to use --thumb.
Table 5: S for the ARM C compiler on Dhrystone 2. 1.
References:
Archives