Improve software through memory-oriented code optimisation

Optimisation metrics for compiled code are not always measured in execution clock cycles on the target architecture. Consider modern cellular telephone or wireless devices, which may download executables over a wireless network connection or backhaul infrastructure. In such cases, it is often advantageous for the compiler to reduce the size of the compiled code that must be downloaded to the wireless device. By reducing the size of the code, savings are achieved in terms of bandwidth required for each wireless point of download.

Optimisation metrics such as memory system performance of compiled code are often important to developers. These are metrics correlated to the dynamic run-time behaviour of not only the compiled code on the target processor, but also the underlying memory system, caches, DRAM, and buses, etc.

By efficiently arranging the data within the application or, more specifically, the order in which data and corresponding data structures are accessed by the application dynamically at run-time, significant performance improvements can be gained at the memory-system level. In addition, vectorising compilers can improve performance due to spatial locality of data when SIMD instruction sets are present and varying memory-system alignment conditions are met.

The next section describes optimisation techniques that may be used to improve application code size. The first techniques presented fall under the category of compiler "flag mining", which is the means by which different permutations of compile-time options are used to achieve the desired results on generated code. In addition, lower-level system details are presented, such as application binary interfaces and multiple encoding instruction set architectures, as vehicles to further reduce code size in the presence of resource-constrained systems.

Code size optimisations
In compiling a source code project for execution on a target architecture, it is often desirable for the resulting code size to be reduced as much as possible. Reasons for this pertain to both the amount of space in memory the code will occupy at program run-time and the potential reduction in the amount of instruction cache needed by the device. In reducing the code size of a given executable, a number of factors can be tweaked during the compilation process to accommodate this need.

Compiler flags and flag mining. Typically, users will begin by configuring the compiler to build the program for size optimisation, frequently using a compiler command line option such as—Os, as is available in the GNU GCC compiler as of version 4.5. When building for code size, it is not uncommon for the compiler to disable other optimisations that frequently result in improvements in the run-time performance of the code. Examples of these might be loop optimisations such as loop unrolling, or software pipelining, which typically are performed in an attempt to increase the run-time performance of the code at the cost of increases in the compiled code size. This is due to the fact that the compiler will insert additional code into the optimised loops such as prologue and epilogue code in the case of software pipelining, or additional copies of the loop body in the case of loop unrolling.

In the event that users do not want to disable all optimisation or build exclusively at optimisation level—O0 with code size optimisation enabled, users may also want to disable functionality such as function inlining via either a compiler command line option or compiler pragma, depending on the build tools system and functionality supported. It is often the case that at higher levels of program optimisation, specifically when optimising for program run-time performance, compilers will attempt to inline copies of a function, whereby the body of the function code is inlined into the calling procedure, rather than the calling procedure being required to make a call into a callee procedure, resulting in a change of program flow and obvious system side effects. By specifying either as a command line option or a via a customer compiler pragma, the user can prevent the tools from inadvertently inlining various functions which would result in an increase in the overall code size of the compiled application.

When a development team is building code for a production release, or in a user case scenario when debugging information is no longer needed in the executable, it may also be beneficial to strip out debugging information and symbol table information. In doing this, significant reductions in object file and executable file sizes can be achieved. Furthermore, in stripping out all label information, some level of IP protection may be afforded to the user in that consumers of the executable will have a difficult time reverse engineering the various functions being called within the program.

Target ISA for size and performance trade-offs
Various target architectures in the embedded space may afford additional degrees of freedom when trying to reduce code size of the input application. Quite often it is advantageous for the system developer to take into consideration not only the algorithmic complexity and software architecture of their code, but also the types of arithmetic required and how well those types of arithmetic and system requirements map to the underlying target architecture. For example, an application that requires heavy use of 32bit arithmetic may run functionally correctly on an architecture that is primarily tuned for 16bit arithmetic; however, an architecture tuned for 32bit arithmetic can provide a number of improvements in terms of both performance, code size, and perhaps power consumption.