MileStone: Multi-Objective Compiler Framework

• MileStone is a multi-objective compiler framework that models phase ordering as a constrained optimization problem over execution time, code size, and energy consumption.
• It leverages a graph neural network for performance prediction and reinforcement learning to explore compiler pass sequences, maintaining a self-evolving database of optimization outcomes.
• Experimental results show up to a 45% reduction in execution time and improved energy adherence compared to conventional LLVM optimization levels, highlighting its potential for energy-constrained systems.

Searching arXiv for the MileStone compiler framework and closely related compiler phase-ordering work. MileStone is a multi-objective compiler phase-ordering framework for graph-based IR-level optimization that models compiler phase ordering as a constrained optimization problem over execution time, code size, and energy consumption. It represents programs as graphs, predicts performance metrics with a graph neural network, explores pass sequences with a reinforcement-learning agent, and maintains a self-evolving database of compiler transformations and measured outcomes. In the reported experiments, it finds strong Pareto-optimal solutions, matches energy limits more accurately than LLVM optimization levels and other related techniques, and reduces execution time by up to 45 percent under the same energy budget (Sadr et al., 22 May 2026).

1. Problem setting and conceptual scope

Compiler phase ordering concerns the order in which optimization passes are applied to a program’s intermediate representation so that the generated code is “best” under one or more criteria. MileStone treats this as difficult for four stated reasons: the search space is combinatorially large; pass interactions are non-linear and program-dependent; execution time, code size, and energy consumption often conflict; and fixed optimization levels such as -O1, -O2, and -O3 are hand-designed heuristics that are fixed across programs and not tailored to user constraints (Sadr et al., 22 May 2026).

Within that formulation, MileStone departs from fixed-level compilation by explicitly targeting trade-offs among three objectives: execution time, code size, and energy consumption. The paper states that aggressive transformations such as inlining, unrolling, or vectorization may reduce execution time but increase code size and energy, so the system is not designed around a single universal optimization target. The framework is therefore organized around Pareto-optimal solutions and user constraints, especially energy budgets.

A common misconception addressed by the framework is that standard optimization levels suffice as a practical proxy for the broader phase-ordering problem. The paper argues that such levels occupy only a tiny region of the possible ordering space and cannot systematically navigate multi-objective trade-offs. In that sense, MileStone is not presented as a new optimization level, but as a constrained search-and-prediction system over pass/directive sequences.

2. Multi-objective formulation

MileStone formalizes compiler optimization as a weighted objective under an energy target. The paper defines a weighted objective in which $\mu$ controls the importance of code size versus execution time, $q$ is a scaling constant used to normalize code size numerically, and the optimization is performed subject to an energy target. Larger $\mu$ prioritizes smaller code size; smaller $\mu$ prioritizes lower execution time (Sadr et al., 22 May 2026).

This scalarization is embedded in a broader Pareto view. The paper explicitly frames the desired outputs as Pareto-optimal solutions over execution time, code size, and energy, meaning that improving one objective would worsen another. The formulation is therefore hybrid: a weighted objective supports controllable trade-offs, while Pareto-optimality provides the conceptual criterion for evaluating the search results.

The reinforcement-learning component uses an episodic final reward rather than intermediate shaping. At terminal time $t=T$, the reward penalizes predicted code size, penalizes deviation from the target energy budget, and penalizes predicted execution time; intermediate rewards are zero. This design makes the agent optimize end-of-sequence compiler outcomes rather than local heuristics. A plausible implication is that the framework treats pass ordering as a delayed-credit assignment problem over a large structured action space, but the core paper states this only through its Markov decision process formulation and final-reward design.

3. System architecture

MileStone consists of four components: Graph Generator (GG), GNN-based Performance Predictor (GNNPP), RL-based Multi-Objective Explorer (RLMOE), and RL-based Database Generator (RLDBG) (Sadr et al., 22 May 2026).

Component	Role	Key output
GG	Extracts a Control and Data Flow Graph from LLVM IR	CDFG
GNNPP	Predicts code size, execution time, and energy	Metric estimates
RLMOE	Searches compiler pass/directive sequences	Candidate solutions
RLDBG	Expands the database through exploration and profiling	Labeled optimization data

The Graph Generator extracts a Control and Data Flow Graph from LLVM IR after front-end compilation. In the paper’s CDFG model, nodes are LLVM instructions and basic blocks, while edges represent control-flow relations and data dependencies. This graph is the common representation used by both the predictor and the search policy.

GNNPP is built as a Graph Convolutional Network. Each node uses a 10-dimensional binary feature vector: one bit indicates whether the node is a basic block or an instruction, and nine bits encode one-hot instruction type for the common LLVM IR opcodes alloca, load, store, add, sub, mul, div, icmp, and call. After GCN propagation, the model applies mean pooling to obtain a graph-level vector, followed by three fully connected layers with leaky ReLU activations. The paper states that three GNN models with the same architecture are used separately for code size, energy, and execution time prediction.

RLMOE performs the search over compiler pass/directive sequences. Its state includes a partially assigned CDFG, a $192 \times 1$ graph embedding, the current node identifier, CDFG metadata, and the energy constraint target. Its action selects whether and how to apply a directive or pass to the current node. The framework supports either DQN or PPO for this exploration process.

RLDBG is the data-generation mechanism. It compiles programs to LLVM IR, extracts CDFGs, uses RLMOE to explore many optimization sequences, profiles resulting binaries, and stores graphs, sequences, and measured metrics. The paper characterizes this as a self-evolving database because improved exploration produces new labeled samples, which in turn improve the predictor.

4. Learning pipeline and optimization dynamics

The optimization loop couples supervised prediction and reinforcement learning. GNNPP is trained on labeled CDFG–metric pairs generated by RLDBG. For GNNPP training, the paper reports mean-squared logarithmic error for energy and code size, mean absolute error for execution time, Adam with learning rate 0.01 and exponential decay, 200 epochs, and batch size 32 (Sadr et al., 22 May 2026).

RLMOE is trained over 1050 unique $$(\text{CDFG}_{\text{index}}, \text{Energy}_{\text{target}})$$ tuples, each revisited 8 times, for a total of 3000 episodes. The reported optimizer is Adam with learning rate 0.008, discount factor $\gamma = 0.95$, exploration $\epsilon = 0.08$ with decay, reward weight $\beta = 5$, scaling constant $q$0, and trade-off settings $q$1. PPO is implemented with the standard clipped surrogate objective and value loss, while DQN uses a temporal-difference target and replay-based loss.

The self-improvement mechanism is central to the framework’s design. RLDBG generates more data; the database grows; GNNPP becomes more accurate; better predictions improve RL search; improved search produces better samples; and these are added back into the database. The paper presents this as a way to reduce redundant profiling because future candidates can increasingly be estimated rather than always executed physically.

The generalization objective is also explicit. The paper defines an optimization objective over a set of training CDFGs, formalizing policy learning across graphs rather than overfitting to a single program. It also notes that a pretrained RLMOE can be used directly for inference on a new CDFG or fine-tuned for higher-quality solutions.

5. Experimental evaluation

The primary benchmark source is PolyBench, with gemm, 3mm, and floyd-warshall reserved for inference and generalization testing (Sadr et al., 22 May 2026). The implementation uses StellarGraph for GNNPP, TensorFlow 2 for RLMOE, and the reported hardware is a Linux workstation with an NVIDIA RTX 3090 Ti GPU, Intel Core i7-1165G7 CPU, and 24 GB RAM.

The comparison set includes LLVM optimization levels -O1, -O2, and -O3; heuristic baselines GA and PSO; standalone RL baselines DQN and PPO; and the related learning-based framework POSET-RL. The paper emphasizes that POSET-RL focuses on -Oz-style optimization, uses IR2Vec-style representation, does not perform true multi-objective optimization, and lacks the graph-based CDFG representation used by MileStone.

The paper reports that two GCN layers yield the best predictive performance, which it connects to the over-smoothing issue in deeper GCNs. For search quality, RLMOE with either DQN or PPO finds the strongest Pareto-optimal solutions across the tested benchmarks and outperforms DQN, PPO, GA, PSO, and LLVM -O1/-O2/-O3. PPO is reported to perform better on larger or more complex programs, while DQN remains competitive.

Energy-budget adherence is a central quantitative result. Across 336 discrete energy constraints, reported matching rates include 90.2% for RLMOE-PPO and 89.3% for RLMOE-DQN at $q$2, compared with 83.6% for standalone PPO, 84.5% for standalone DQN, 68.4% for GA, 64.6% for PSO, 9% for -O3, 6% for -O2, and 3% for -O1. At $q$3, the reported matching rates are 91.2% for RLMOE-PPO and 93.1% for RLMOE-DQN; at $q$4, they are 92.1% and 91.2%, respectively. The headline performance claim is that MileStone achieves up to 45% execution-time reduction under the same energy budget.

6. Significance, practical implications, and limitations

MileStone’s main significance lies in treating compiler phase ordering as genuinely multi-objective and constraint-aware rather than as a fixed-policy heuristic problem. The paper’s stated contributions are a multi-objective phase-ordering framework, graph-based IR modeling through CDFGs, a GNN performance predictor, an RL-based multi-objective search engine, a self-evolving database, and strong empirical results on Pareto-front quality, energy-constraint satisfaction, and execution-time reduction (Sadr et al., 22 May 2026).

The practical implication stated in the paper is that compilers could optimize differently for battery-constrained mobile or embedded systems, throughput-oriented servers, code-size-sensitive deployments, and mixed-objective settings in which users choose the trade-off. This suggests a user-aware compiler configuration model rather than dependence on fixed optimization levels.

The paper also identifies limits of the current evaluation. It implies that the benchmark set is controlled and primarily PolyBench-derived, that prediction quality depends on database coverage, and that further work is needed for larger industrial workloads, more architectures, richer hardware and microarchitectural models, dynamic optimization settings, transfer learning, and runtime profiling signals. Accordingly, MileStone is best understood as a framework-level proposal with strong benchmark evidence, rather than as a closed solution to all compiler phase-ordering regimes.

In summary, MileStone defines a graph-based, learning-driven framework in which LLVM IR is converted to CDFGs, performance is predicted with GNNs, pass sequences are searched with DQN or PPO under explicit user constraints, and the entire system improves through a self-evolving database. Its reported results position multi-objective compiler phase ordering as a practical optimization problem over execution time, code size, and energy rather than as an extension of fixed optimization levels alone.