Exploring compiler optimizations for enhancing power gating

Abstract

Power gating is a circuit level technique for reducing standby leakage in a circuit block by cutting off paths in it between the supply and the ground. A processor architecture that supports power gating of its resources may provide instructions that activate and deactivate those resources as part of the instruction set architecture level. Adequate compiler support is then required so that the power gating instructions can be inserted into the code to deactivate the resources that remain idle for long periods of time during program execution. However, the resource usage in a program depends on the code generated by the compiler. Thus, the code transformations performed by the compiler has an influence on the power gating opportunities of the processor resources. In this work, we explore target independent compiler optimizations that modify the functional unit usage in the loops of a procedure to enhance the opportunities to deactivate functional units in an embedded processor architecture. The optimizations performed on the code are sparse conditional constant propagation, lazy code motion, weak strength reduction, and operator strength reduction. Insertion of power gating instructions is performed by inspecting the idleness of the units in the regions enclosed within loops. We model the processor architecture with power gating support around an ARM core and use the SUIF framework for compiler support. Finally, we use the Simplescalar-ARM distribution to perform power and performance evaluation with a set of benchmarks from MiBench and MediaBench suites. Experimental results indicate that the integer multiplier in the processor core can be power gated for upto 99% of its idle cycles, for integer benchmarks, and upto 93%, for floating point benchmarks, when all the optimizations are performed. Moreover, the energy due to leakage in the functional units for the code with all the optimizations performed can be upto 51% lower, for integer benchmarks, and upto 21% lower, for floating point benchmarks, than that for the unoptimized code.