Beyond the Phase Ordering Problem: Finding the Globally Optimal Code w.r.t. Optimization Phases

TL;DR

It is shown both theoretically and empirically that solving the phase ordering problem does not necessarily result in the most efficient code among all programs that a compiler deems semantically equivalent to the input, hereinafter referred to as the global optimal code \wrt optimization phases.

Abstract

In this paper, we propose a new concept called \textit{semantically equivalence} \wrt \textit{optimization phases} \textit{(\sep)}, which defines the set of programs a compiler considers semantically equivalent to the input using a set of optimization phases. We show both theoretically and empirically that solving the phase ordering problem does not necessarily result in the most efficient code among all programs that a compiler deems semantically equivalent to the input, hereinafter referred to as the global optimal code \wrt optimization phases. To find the global optimal code \wrt optimization phases, we present a conceptual framework, leveraging the reverse of existing optimization phases. In theory, we prove that the framework is capable of finding the global optimal code for any program. We realize this framework into a technique, called \textit{iterative bi-directional optimization (\tool)}, which performs both the normal and reverse optimizations to increase and decrease the efficiency of the generated code, respectively. We evaluate \tool on C/C++ files randomly extracted from highly mature and influential programs (\eg, Linux kernel, OpenSSL, Z3). Results show that \tool frequently generates more efficient code -- measured by either code size or runtime performance -- than exhaustive search, which is the solution to the phase ordering problem. We also find by simply incorporating \tool's reverse optimization phases, the effectiveness of the optimization of state-of-the-art compilers (\eg, GCC/LLVM) can be significantly improved.

Figures (4)

• Figure 1: (\ref{['fig:ori1']}) shows an input program $P_a$. (\ref{['fig:comA1']}) shows the code $P_b$ that LLVM compiles $P_a$ into using the optimal ordering of optimization passes. Since the result of occupies four bits, and the result of vacates the four right most bits, the bitwise or operator in $P_b$ achieves the same effect as the addition operator in $P_a$ but runs faster. (\ref{['fig:comB1']}) shows another piece of compiled code $P_c$ related to $P_a$ and $P_b$. For illustration purpose, all compiled code are displayed at the source level.
• Figure 2: Optimizing $P_d$ along two different paths. In the first sequence of optimizations ($P_d\rightarrow P_e\rightarrow P_a\rightarrow P_b$), in $P_d$ is optimized into in $P_e$. Then in $P_e$ is optimized into in $P_a$. Next, the addition operator "+" in $P_a$ is replaced with the bitwise operator "|" in $P_b$. In another sequence of optimizations ($P_d\rightarrow P_c$), and in $P_d$ is combined into in $P_c$.
• Figure 3: The optimization of program $X$. Every box in the diagram represents a program while every arrow represent a optimization pass.
• Figure 4: (\ref{['fig:oriex']}) depicts the original function; (\ref{['fig:rev']}), which is resulted from the reverse optimizations, can be optimized into a more efficient code (depicted in (\ref{['fig:opt']})) than (\ref{['fig:oriex']}) can ever be optimized into (which is itself).

Theorems & Definitions (9)

• Definition 2.1: Semantic Equivalence w.r.t. Optimization Phases
• Definition 3.1: The Globally Optimal Code w.r.t. Optimization Phases
• Theorem 3.1: Existence of The Global Optimum w.r.t. Optimization Phases
• Theorem 3.2: Solving the Phase Ordering Problem $\ne$ Finding the Globally Optimal Code
• Theorem 3.3: The relationship between the two problems
• Theorem 3.4: Undecidability
• Theorem 3.5: NP-hardness
• Theorem 4.1: Capability of Finding the Global Optimum w.r.t. Optimization Phases
• Definition 4.1: The Minimum Set of Optimization Passes to Reverse