ProfiX: Improving Profile-Guided Optimization in Compilers with Graph Neural Networks
Authors: Huiri Tan
Juyong Jiang
Jiasi Shen
Venue: NeurIPS 2025 poster ()
Keywords: Optimizing Compiler
Program Optimization
Graph Neural Network
Primary area: applications

Abstract: Profile-guided optimization (PGO) advances the frontiers of compiler optimization by leveraging dynamic runtime information to generate highly optimized binaries. Traditional instrumentation-based profiling collects accurate profile data but often suffers from heavy runtime overhead. In contrast, sampling-based profiling is more efficient and scalable when collecting profile data while avoiding intrusive source code modifications. However, accurately collecting execution profiles via sampling remains challenging, especially when applied to fully optimized binaries. Such inaccurate profile data can restrict the benefits of PGO. This paper presents ProfiX, a machine learning-guided approach based on hybrid GNN architecture that addresses the problem of profile inference, aiming to correct inaccuracies in the profiles collected by sampling. Experiments on the SPEC 2017 benchmarks demonstrate that ProfiX achieves up to a 9.15\% performance improvement compared to the state-of-the-art traditional algorithm and an average 6.26\% improvement over the baseline machine learning models. These results highlight the effectiveness of ProfiX in optimizing real-world application profiles.

PROFIX: Improving Profile-Guided Optimization in Compilers with Graph Neural Networks
Huiri Tan'
Juyong Jiang
Jiasi Shen
The Hong Kong University of Science and Technology
2 The Hong Kong University of Science and Technology (Guangzhou)
(htanaj, sjs}@cse. ust.hk, jjiang472ccomect. ust. .k
Abstract
Profile-guided optimization (PGO) advances the frontiers of compiler optimization by leveraging dynamic runtime information to generate highly optimized binaries. Traditional instrumentation- bbastddo--baddddddee profiling collects accurate profile data but often suffers from heavy runtime overhead. In contrast, sumpling-basee based profiling is more efficient and scalable when collecting profile data while avoiding intrusive source code modifications. However, accurately collecting execution profiles via sampling remains challenging, especially when applied to fully optimized binaries. Such inaccurate profile data can restrict the benefits of PGO. This paper presents PROFIX, machine learning-guided approach based on hybrid GNN architecture that addresses the problem of profile inference, aiming correct inaccuracies in the profiles collected by sampling. Experiments on the SPEC 2017 benchmarks demonstrate that PROFIX achieves up to 9.15% performance improvement compared to the stte-of-theear traditional algorithm and an average 6.26% improvement over the baseline machine learning models. These results highlight the effectiveness of PROFIX in optimizing real-world application profiles.
Introduction
Compilers play critical role in transforming high-level source code into efficient machine- level instructions. Beyond basic translation, modern compilers employ numerous optimiza- tion techniques to improve program perfor- mance, reduce memory usage, and ensure faster execution [33 37 47 [48]. Compiler optimiza- tions, such as loop unrolling, function inlining, and instruction scheduling, aim to exploit hard- ware features effectively and improve overall program efficiency [14 17 26 55). Profile- guided optimization (PGO) has emerged as
Table 1: High-level comparison of Sampling- based and ① Instrumentation-basse PGO. Advan- tages are highlighted and annotated with check- marks. Sampling- baaeed PGO offers high perfor- mance with low overhead, without requiring intru- sive modifications code, making it well-suited for scalable deployment, but is limited in accuracy.
Type Efficieccy
Non-Intrusive
Scalable
Accuracy
x
x
x
powerful optimization technique for improving program performance by incorporating runtime exe- cution profiles into the optimization pipeline of compilers (8] By identifying frequently executed hot regions of code, PGO enables compilers to foeus optimizing the most frequently executed
parts of a program, thereby significantly enhancing performance [17 23
PGO is practiced in two main flavors: instrumentation-ben based and sampling-based, which are summa- rized in Table Instrumentation-bann PGO collects precise profile data by injecting counters and
Cooresponniigg author.
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

logging code during compilation, but incurs substantial runtime overhead. rendering it unsuitable for
production-sed -eclllttoo--nlleeeeeeeeeeeeeeee applications [8. contrast, sampling- canpling-based PGO [2] 40) leverages hardware features such as the Last Branch Record (L.RR) (54) from performance monitoring units (PMUs) (36] to collect profile data with negligible overhead, and it does not require any intrusive modification to program code. These characteristics make sampling-basee baangg PGO particularly well-suited for de- profiles
ployment in latency-sensitive environments like data centers. Moreover, sampling are extensively used in binary-level and post-link optimization frameworks [41 42) Despite its low overhead, the effectiveness of sampling-based PGO is fundamentally constrained by the accuracy of the collected profiles. Noise, missing samples, and imprecise attribution of sampling- sampinng-based profiles can degrade optimization quality, ultimately resulting in suboptimal binary performance (20). To this end, previous work has proposed to traditional network flow algorithms, such minimum cost flow formulation, to infer more accurate profiles 62) However, these techniques are unable to produce faithful profiles from sampled data because they rely on hand-tuned heuristics rather than learning progran-specific patterns-they they systematically under-estimate hot paths in sparse-sampled code, leaving much of the potential of sampling- seaseinn--asedd PGO untapped.
Recent advances in machine learning (ML) have shown great promise in code generation and compiler optimization 77 27 32 35 ST 60 61]. ML models have been successfully applied to tasks such as automatic tuning of compilation parameters 2 68) and reinforcement learning-base -ased register allocation [25 [9]. These successes highlight the potential of machine learning automate and enhance traditional compiler heuristics, paving the way for more adaptive and intelligent optimization pipelines. Among recent ML techniques, graph neural networks (GNNs) [6)] have been widely used in compiler optimization [3 [2] due to their ability to model structured program representations. Programs naturally formed by graphs, such as control-flow graphs (CFGs) and data-flow graphs (DFGs) []] which encode rich semantic and structural information. By operating directly on these graph representations, GNNs can capture complex program behaviors and inform optimization decisions more effectively and accurately than traditional feature-based models (49)
In this work, we take the first step toward applying GNNs, and even ML-based approaches, to address the profile inference problem in the domain of compiler optimization. Our GNN- model and profile data
framework bridge the gap between low-fidelity sampled profiles and the required for effective sampling-bass basen PGO. By learning to infer accurate exccution frequencies from noisy and incomplete samples, our method improves the reliability of PGO and enhances overall compilation performance. The main contributions are summarized as follows:
We propose machine learning guided approach to improve sampling-basee profile-guided optimization, introducing novel graph neural network architecture specifically designed for profile inference tasks.
We develop PROFIX, end-to-end framework that integrates GNN-based profile inference model into the LLVM infrastructure (30), enabling accurate profile reconstruction without instrumentation, demonstrating its practicality and compatibility with real-world compilers.
We conduct extensive experiments on widely used benchmark suites, showing that our approach significantly improves profile inference accuracy over existing methods and yields measurable performance gains in the optimized binaries.
The rest of the paper is organized as follows: Section 2 introduces the background of PGO and reviews the related work, Section Section presents the experimental setup and results, and Section concludes the paper.
3 presents our design of the model and the PROFIX framework,
Background and Related Work
Profile-Guided Optimization. Profile-guided optimization (PGO) improves code generation by allowing the compiler to observe the dynamic behavior of the program and, informed by this feedback, apply transformations such as aggressive inlining, basic block reordering, and loop unrolling, for which static analysis alone often makes suboptimal decisions [17 27 35)... Instrumentation-Dass
PGO embeds counters into the binary and therefore yields highly accurate profiles but intro- duces heavy runtime overhead, rendering it impractical for latency-critica services 88 43) Sampling-based PGO, instead, leverages hardware performance- monitorrig units to collect events with virtually no overhead, making it suitable for deployment at data-center scale [40]. However, sam- pling inherently introduces stochastic noise [63 66 and sparsity into the collected profiles, which can

---

BB;
BB, 10
40
g3 80
B
8
Bus
30
20
BBst7
BB,
BBc 30
BB 3
BBg
40
10
B3 1100
BB,:10
(a) Real Execution
(b) Ground Truth
(c) Sampled Data
Figure 1: Motivating example of the inaccuracies in sampling saapling-bbsedd profiles. (a) The real execution count of a control flow graph, branch frequency annotated in edge. (b) Expected sampled count given the sampling rate of TO (c) We observe three key types of distortions. First, underestimation of BB2, where the execution count is significantly lower than the ground truth due to insufficient sampling, which may cause the compiler to deprioritize this basic block during optimization, ultimately resulting in suboptimal performance. Second, overestimation in BB3 and BB;, where the sampled execution counts are inflated compared to the ground truth. This can mislead the compiler into making incorrect optimization decisions, such prioritizing cold regions of the program for inlining, which may increase binary size and degrade runtime performance. Finally, the issue of a dangling block [20) arises with BB,, which has execution count marked as unknown, indicating that it was not sampled at all. This missing data prevents the compiler from accurately modeling control flow dependencies and can result in misaligned basic block placements incorrect branch predictions.
mislead the compiler during optimization (20). Consequently, the central challenge becomes profile inference, aiming at reconstructing faithful execution profile from these incomplete, sample-driven observations so that the compiler can reap the full benefit of low-overhead PGO.
Profile Inference Problem. Sampling-basse profiles often suffer from inaccuracies, such as under- estimation, overestimation, and missing execution counts, which illustrated Figure [ Such distortions stem from the probabilistic nature of hardware sampling and mislead PGO by providing unreliable execution frequency signals. Traditional solutions to this problem use the Minimum-Cost Flow (MCF) formulation [10 31 57). which models execution frequency inference as a flow optimiza- tion problem that minimizes the discrepancy between sampled and inferred counts while preserving flow conservation. Although effective in principle, MCF-based methods face limitations such as scalability on large and complex CFGs. To address this issue, the ofte-offtheear network flow algorithm, Profi (20), introduces domain-specific heuristics and CFG transformations to accelerate MCF solving and improve practicality. However, Profi remains constrained by the rigidity of the MCF formulation, which cannot capture higher-order execution patterns or adapt to irregular control-flow structures. Moreover, its reliance on compiler-specifie heuristics may lead to biased inferences when generalizing to unseen programs. These limitations motivate the need for flexible, data-driven alternative that can generalize across program domains and scale to large workloads. In this work, we formulate profile inference learning problem and propose graph-based neural approach that combines structural and sequential reasoning to infer high-fidelity execution frequencies.
Graph Neural Networks (GNNs) have emerged as powerful tool for modeling structured data represented as graphs [34 67). In the context of program optimization. GNNs are particularly suitable because programs can be naturally represented as various types of graphs, such as control-flor graphs and flow graphs [43 (2). These graph representations encode rich structural information, which GNNs can leverage to learn meaningful representations for tasks like profile inference. A classical GNN model follows the message passing paradigm (15), where node embeddings are iteratively updated by exchanging information with neighboring nodes. Specifically, at each iteration t, the embedding h." of a node is updated based on the embeddings of its neighbors. The message passing process involves two key steps: aggregation and update, which can be formally described as follows:
Graph Neural Networks.
m AGGREGATE (1) (nh ((E)))
(1)
h (4) m
(PDATE())
(t-1) (h(--)),m!))
(2)
3

---

N-Stack
Liear
Laye
SAUR Nusaaa Laya
Kill & Nam
Lincar
CRGs
Figure 2: Overview of the model structure in PROFIX for the profile inference problem. Given control-flow graph, we extract basic block features and process them through two parallel encoders: an LSTM for sequential dependencies and GraphSAGE convolution for structural information. The outputs are fused and passed through stacked SAGEAttentio Layers, each combining LSTM- augmented graph reasoning. The final representation is projected through softmax head to infer normalized execution frequencies. A zoomed-in view (right) illustrates the internal structure of the SAGEAttention Layer, which integrates GraphSAGE, GAT, and a feedforward module with residual connections and normalization.
based sequence modeling and attention-auge -annntionnngmenteed
where (w) denotes the set of neighbors of e, and ha ((-1) denotes the embedding neighbor u from the previous iteration. The aggregated message m (t) combined with the current embedding of node v to produce an updated embedding. Advances in GNN architectures have significantly enhanced their ability capture complex dependencies in program graphs. Traditional message-passing neural networks (MPNNs) (15) often struggle with capturing long-range dependencies. To address these limitations, Graph Attention Networks (GAT) (58) and GraphGPS (45) introduce attention-based mechanisms that enable nodes to weigh neighboring features adaptively, allowing the model to focus on the most relevant control-flow relationships. Prior work (56) proposes a hybrid model to capture the specific pattern of directed acyclic graph, while the CFG often contains a loop. Meanwhile, GraphSAGE [19] provides an inductive learning framework that generalizes well to unseen graph structures, making it particularly suited for optimizing new, previously unseen CFGs in compiler workloads. The application of deep learning and GNNs in compiler optimization has been explored in various domains, including register allocation using reinforcement learning 59), automatic loop unrolling decisions (6). and performance prediction for microarchitectural modeling [38 (3).
Methodology
The profile inference problem arises from inaceuracies in sampling- based profile-guided optimization. We next formalize the problem and present the design of the GNN model and the PROFIX framework.
3.1 Problem Formulation
Given control-flow graph of program, represented G (V, F), where V is the of basic blocks and the set of control-flow edges, the goal is to infer accurate execution frequencies for each basic block and edge. Each vertex V is associated with sampled execution count w(v). but these counts are often noisy or incomplete due to sampling errors. Formally, the task is to learn mapping function F G - RVV that predicts execution frequencies s.ned for each basic block i, such that inferred values closely approximate true execution frequencies frree These inferred values reflect more realistic program execution behavior than the sampled execution counts.
3.2 Profile Inference Model
present the design our profile inference model based on graph neural networks in Figure 2 Since the natural graph structure of LLVM IR (30) includes control-flow graphs and data-flow graphs, it particularly well-suited for modeling with GNNs. Given the numerous different CFG structures in diverse real-world programs, aim to develop model with strong inductive gen-

---

eralization capabilities to ensure the model can reliably infer execution profiles for unseen CFGs while maintaining robust performance across varying program structures. Toward this goal, we propose a hierarchical learning paradigm that alternates between sequential learning and graph-based structural learning. By alternating between these two components, our model effectively captures both execution sequences of the program and the CFG structural dependencies, enabling the strong inductive generalization capability of our model for a large variety of CFGs.
3.2.1 Program Feature Extraction
In PROFIX, each basic block (BB) in the CFG is represented as feature vector I; E Rd extracted from LLVM IR. Given CFG G E), where V is the set of basic blocks and E' represents the control-flow edges, we apply learnable linear transformation proj Rdd to project each basic block feature into a latent space, following the reversed post-order traversal in CFG:
h (0)
proj
These feature vectors encode both static properties (c.g., instruction count, control dependencies) and sampled profiling statistics. Details of features are available in Appendix
3.2.2 Hierarchical Representation Learning
To capture both sequential and structural dependencies within the CFG, we employ an alternating stack of LSTM layers, which model sequential dependencies, and Graph Attention layers, which model structural dependencies. This design enables our model to aggregate local neighborhood information while preserving long-range dependencies inherent in control flow.
Sequential Encoding via LSTM. The sequential structure of basic blocks, as reflected in their execution order, is captured by a multi-layer Long Short-Term Memory (LSTM) network ( The LSTM processes the sequence of basic blocks, which are extracted through reversed post-order traversal of the control-flow graph:
Deq LSTM(M; (0))
Structural Encoding via GraphSAGE. While sequential features help the model capture a single execution path of programs, real-world applications often involve complex control-flow graphs rather than flattened sequences. To encode the structural information within the CFG, we employ an inductive graph neural network that can generalize unseen graphs. Specifically, we use GraphSAGE [19], which aggregates information from neighboring nodes to capture the structural dependencies in the CFG. The aggregation function AGG(.) we in PROFIX is mean pooling, and the learned weights W Wago are used to transform the aggregated neighborhood features:
sage h
a (Wage AGG (1 :je (()))
(5)
While LSTM-based encoding and GraphSAGE encode sequential and structural relationships among basic blocks, neither alone fully characterizes program behavior, which involves both localized execution dependencies (sequential patterns) and global structural properties (CFG connectivity). To address this challenge, we fuse the sequential and structural representations by concatenating their embeddings, retaining both execution order and global control-flor information.
Enhanced Inductive Learning with Graph Attention. As illustrated in Figure 2 further refine the representation and enhance feature interactions, we pass fused features through a SAGEAftention Layer, which extends the vanilla GraphSAGE aggregation by incorporating attention mechanisms:
h
SAGEAttention poattenntionn,onass (Aconcat).
(6)
This layer combines GrephSAGE aggregation (Equation 5) with Multi-Head Graph Attention
(GAT) (58). which aggregates information from neighboring nodes with attention weights:
Oij W gu
JEN()
exp (LeakyReLU Wh, @ Why))
0i Σ CREN()) exp (LeakyRel.U [h,, @ Wha)))
(8)
5

---

ASM
Compller Optimization
C/ C++
Binnay
Source Code
Intruncatiiion
pert sampling
Trainiog Phose
Inference Phase
ASA
Binary
LEVM
LEVM
Ground Truth Profile
GNN Model
Sampled Profile
Compilation Pipeline
PGO Pipeline
Training Pipeline
Figure 3: Overview of the PROFIX framework. The system operates two phases: a training phase (blue background) and an inference phase (red background). In the training phase, both sampled and ground-truth profiles are collected for C/C++ programs. The sampled profile is obtained using perf, hardware-based sampling tool, while the ground truth is generated via instrumentation. Both profiles are aligned with the LLVM IR (30] and mapped to control-flor graphs, which serve as the input to the model training pipeline. The trained model learns to reconstruct high-fidelityy execution profiles from noisy samples. In the inference phase, only the sampled profile is required. Given a new program, compile it to LLVM IR and extract CFGs. These CFGs are fed into the trained model to infer execution frequencies for each basic block. The inferred profiles are then passed to the PGO pipeline to guide subsequent compiler optimizations. PROFIX integrates seamlessly with the LLVM infrastructure and supports both static and post-link binary optimization workflows.
The final representation is then passed through a feedforward transformation, enabling the model to selectively focus on important nodes while preserving inductive generalization. To improve stability, the output is normalized using residual connections.
To enhance inductive generalization, we employ a stacked architecture in which LSTM layers and SAGE-Attention layers alternate. This design allows the model to iteratively refine basic block representations by incorporating both local neighborhood information and execution sequence dependencies. This stacked representation learning is repeated across N layers, enable progressive refinement of embeddings. Finally, to infer the execution frequency distribution, we apply a softmax
projection the final representation (N) which ensures that the predicted frequencies form valid probability distribution, consistent with real-world execution patterns.
3.3 Profile Inference Pipeline
As illustrated Figure 3 PROFIX is designed to enable accurate and scalable profile inference within modern compiler infrastructures. Unlike traditional heuristic- based solutions (20). it learns to reconstruct execution profiles directly from sampled data, effectively handling noise, missing coverage, and structural variability in real-world programs. By combining control-flow-wware graph representations with neural inference, PROFIX generalizes across diverse applications and adapts irregular execution patterns that are difficult to model symbolically. It integrates seamlessly into the LLVM toolchain, requires no changes to compiler internals, and supports both training-time supervision and deployment-time inference. Therefore, PROFIX is highly practical for production- scale adoption, enabling high-fideliyy profile-guided optimizations without the cost of instrumentation.
Experiments
We evaluate PROFXX with a diverse dataset covering compiler toolchains (Clang 29 GCC (50
database systems (MySQL [1I), SQLite (13)., and performance benchmarks (SPEC CPU 2017 These applications span a broad range of code complexity, function structure, and execution behavior.
http:::/wwww.ppc.orr/////g

---

Table Dataset statistics across five representative applications used for training and evaluation, For each application, we report the total number of source functions, sampled functions (with available profiles), and filtered functions (after quality control preprocess), along with the median (q-50%) and high-peecenttle (q-90%) number of basic blocks per function to reflect CFG complexity. Total lines of code (I.OC) are also listed to reflect program scale. The dataset includes diverse program sizes and structural complexity, providing robust basis for learning generalizable execution profiles.
Blocks Function
Application
Source Funcs
Sampled Funes
Filtered Funes
Total LOC
4-50%
4-90%
Clang 20.0
354,365
4920
2557
98
264
9,192,184
GCC 14.2
196,337
5120
1643
251
6,672,238
MySQL. 8.32
64,813
2467
1199
269
4,551,087
SQL lite
12,794
235
87
81
630,516
SPEC CPU 2017
274.677
8696
575
153
611
13,815,845
4.1 Dataset Curation
Table 2 summarizes key dataset statistics. SPEC CPU 2017 stands out with the highest CFG complexity, underscoring its value for evaluating profile inference in highly diverse scenarios. For each benchmark, we run a representative workload twice to collect profiles, using sampling-basee and inttrmmentation-basee methods, respectively. The sampling-based profile, obtained via Linux perf, provides noisy execution counts and serves as the model input, while the instrumentation bbased profile offers ground-trut data for supervision. All profiles mapped back to their corresponding LLVM IR [30] CFGs to construct a mifileegrounee dataset. To ensure data quality, we apply several preprocessing steps. We first filter out functions with insufficient sampling data inconsistent basic block structures, as they lack meaningful learning signals. Consequently, we normalize execution counts reduce sampling bias and stabilize training. Finally, extract CFGs for each function, encoding both structure and execution profiles as node and edge attributes.
4.2 Implementation Details
We conduct all training and testing experiments on a server with Intee) Xeo Gold 6444Y CPU (16 Cores), 256 GB RAM, and 2xRTX 5880 GPU (48 GB Memory). Table 3 describes the partition of the collected datasets. The dataset used in the training and testing phase consists of CFGs with profiles collected from Clang, GCC, MySQL, and SQLite. The pro- cessed data is split into training, validation, and test sets with a ratio of 80%/10%//1%% The training objective formulated as a regression problem, where the predicted execution frequencies are optimized align with the ground truth collected from instrumentation. We employ the Root Mean Squared Error (RMSE) Loss during the training phase, which measures the discrepancy between the inferred execution frequencies and the ground-truth profiles. RMSE penalizes large deviations more heavily than small ones, making it well-suited for profile inference tasks where execution frequency errors can significantly impact downstream compiler optimizations. Given a set basic blocks V in a control-flow graph, let f and fume denote the predicted and ground-truth execution frequencies for basic block i, respectively. The RMSE loss is defined as:
Table 3: Overview of dataset partitioning in two experimental phases: ii-distribution training and testing, out-of-distribution evaluation.
Source
Split
Results
Clang 20.0, GCC 14.2
80%, 10%, 10% (train, val, test)
MySQL 8.32, SQLite 3
Fig
SPEC CPU 2017
No split
Tab 4
(Unseen data)
CRMSE
( ped
firue
(9)
iEV
To evaluate the accuracy of our inferred execution profiles, we employ a widely used metric, node frequency overlap (20). the primary evaluation metric report our performance evaluation of PROFIX on SPEC CPU 2017. Given a set of basic blocks V in a control-flor graph, let f and
prred denote the ground truth and inferred execution frequencies for basic block respectively. The
7

---

Table 4: Performance comparison of PROFIX and its ablated variants across SPEC 2017 benchmarks. Each row corresponds to a specific ablation, evaluating the impact of removing or replacing individual components, including
the sequence encoder, SAGEAttention layer, and D removed input features. Results are reported in terms of overlap (%), with the highest value for each column highlighted in bold.
graph reasoning modules, parts of the
Group
Variant
Benchmarks
Average
petlhench
gec
omnncppp
deepsjong
leala
partst
povnn
imtgrick
LSTM w/ GRU
91.62
97.20
93.75
57.57
92.57
97.03
92.70
92.55
91.90
91.33
91.99
93.33
86.51
94.70
36. 16
58.01
93.56
90.87
98.68
92.37
wio CIN
88.37
90.41
91.75
89:51
01.20
88.80
90.98
50.97
78.48
91.70
89.74
95. 56
90.48
w/ SAGE
93.99
92.44
93:18
90.98
91.05
91.93
93.62
82. 10
84,26
93.17
91.29
97.
92.42
w/ GAT
95.79
92.20
90.48
90.50
93.82
39.55
94.94
355.47
92.07
94.33
94.78
97.86
92.82
w/ QCN
91.26
83.32
$4.95
92.90
90.61
91.72
SAGE
92.
87
Atteation
90.64
73.70
78.27
58.53
90.17
91.29
Food-Forward
92.15
93.73
91.78
$8.90
73.42
83.05
93.87
93.00
95.55
92.75
Suce. Peatures
88.54
99.42
89.98
58.57
59.81
87.19
90.33
$4.91
53.73
90.57
89.86
92.24
90,06
Chrl-Flow Info
90.88
91.47
91.96
91.00
92.27
89.59
92.03
56. 4M
85.67
91.91
91.06
93.52
91.32
Memary Ops
92402
92.25
92.63
91.81
93.03
90.69
98.
$7.86
87.33
92.63
92.01
94.33
92.21
Ari..I.ag' Ops
90.72
91.26
91.74
90.58
91.81
89.17
91.
85.95
85.16
91 18
90:57
93.03
91.14
Call/intiis
92.61
92.73
93.07
92.13
93.43
91,08
93.55
88.22
87.86
92.83
92:31
94.51
92.65
PRORX
Full Model
90.85
93342
overlap score is defined as follows:
Eisy min (ftti gorod
Overlap
(10)
Σiev f!ue
This metric measures how much of the true execution profile is accurately captured by the inferred profile, with higher values indicating better inference quality. Appendix proovddes more detailed explanation about the rationality of the overlap metric.
4.3 Profile Inference Capability
We evaluate the profile inference capability of our model against several representative base- lines under the hyperparameters listed in Ap- pendix [D] including both sequence-based and graph-based approaches, on held-out test set. reports two key metrics: root mean square error (RMSE), which measures the nu- merical accuracy of execution frequency pre- diction, and overlap, which captures the align- ment between predicted and ground-truth basic block execution frequencies. PROFIX achieves the best overall performance and accuracy. with an RMSE of 0.0341 and an overlap of 93.50%. These results confirm that combining sequential and structural reasoning in a unified architecture significantly improves profile inference quality.
Overlip (4)
0.10
696
0.204
95 505
95
88%
$1.2%
67.55%
90
RMSE
0.08
85
0.06
0.22
-00
Figure E
0.04
5.03
LSTM
GCN
Gropht5AGE
GiN
GAT
GraphoPS
DAGNN
Pranit
70
Figure 4: Performance comparison of our model and baseline methods in terms of prediction accu- racy (RMSE) and consistency (overlap). Lower RMSE and higher overlap indicate better profile inference quality. PROFIX achieves the best over- all result compared to all of the baselines.
4.4 Training Convergence Analysis
To further analyze the efficiency and stability of our approach, we compare the training and validation loss curves of all models over 60 epochs. Figure presents the training loss trajectories and the validation loss curves. From the training loss curves, we observe that PROMX converges significantly faster than baselines, achieving a lower final training loss. While GraphSAGE and GAT exhibit relatively stable convergence, their final loss remains higher, which indicates that they struggle to generalize across different CFG structures. The LSTM-based model shows slower convergence and higher training loss, which supports the hypothesis that sequential models are less effective at capturing graph-based execution patterns. In terms of validation loss, PROFIX maintains lower validation error throughout training, demonstrating strong inductive and generalization capability. In contrast, models such GCN and GIN exhibit higher validation loss fluctuations, indicating
8

---

Table 5: The overlap (%) results on the SPEC CPU 2017 benchmarks. Symbolic represents the State-of-tee offtthe-art traditional profile inference algorithm, while the rest are neural network baselines.
Benchmarks
Symbolic
Neural Models
20
58
Gruph
[6
petlbench
86.68
89.76
77.61
92.31
77.74
78.74
91.85
90.37
95.83
gee
mef
95,97
92.31
89.94
84.93
93.50
91.48
94.12
92.06
96.26
onnectp
93,76
87.72
82.52
82.34
80.04
88.44
93.98
x264
93.12
94.01
85.47
94.13
86.20
86.82
92.49
91.67
94.39
deepsjeng
87.89
91.70
94.91
91.43
94.15
92.97
93.40
92.55
90,78
91.02
80.03
82.51
85.91
81.08
82.35
85.64
84,73
85.74
parest
91.39
89.95
86.32
94.05
86.33
83.54
91.77
90.90
95.12
powray
92.48
87.43
82.54
81.78
83.43
90.09
92.99
imugick
90.14
87.69
75.77
93.83
75.58
81.95
94.10
93.15
98.85
Average
91.76
89:00
86.62
90.47
82.64
84.03
89.42
87.95
93.42
overfitting specific function structures. Notably, LSTM struggles with stability, which indicates its difficulty in adapting to programs with CFG dependencies.
4.5
Ablation Study
To demonstrate the contribution of each archi- tectural component, Table presents ablation study, where key modules in our model are sys- tematically removed or replaced.
Training Loss Comparison
BAGVM
24
Prote SAGE
GA
-PS
GCN
55T
10-5
Trairinn Less
Variants on sequence modeling. We eval- uate the role of sequential encoding by modi- fying the LSTM-based encoder. Removing the LSTM entirely results in notable accuracy degra- dation, indicating the importance of capturing exccution order among basic blocks. Replacing with a simpler GRU unit also leads to perfor- mance drops, though less severe, suggesting that the higher expressive capacity of LSTM offers benefits in modeling sequential dependencies.
6x
4
4x10-
10
40
500
Epoch
Validation Loss Comparison
0.14
DAGVI
24
Proti SAGE
Valication Loss
0.12
0.10
Variants on graph reasoning. To examine
the impact of structural modeling, we replace the GNN components with various alternatives. Re- moving all GNN layers and using Multi-Layer Perceptron significantly impairs performance, confirming the importance of graph-based rea- soning. Among inductive GNN variants, sub- stituting our SAGEAttention layer with Graph- SAGE or GAT leads to significant degradation. In contrast, using transductive GCN model, which is unable to generalize to unseen graphs, results in consistently lower accuracy.
0.06
0.04
10
20
30
40
50
Epach
Figure 5: Training and validation loss curves for PROFIX and baseline models over first 60 epochs. Our model converges faster and achieves lower final loss on both training and validation sets, indi- cating superior inductive generalization capability.
Variants on SAGEAttention components. We further dissect the SAGEAttention layer by ablating individual components. Removing GraphSAGE aggregation, the attention mechanism, or the feedforward transformation each causes measurable performance declines, highlighting their complementary roles in enabling expressive and context-aware message passing.
Variants on Input Features. The feature ablation results show that all feature groups contribute to the performance. Removing successor or control-flow features causes the largest accuracy drop, confirming their importance for capturing execution dependencies and CFG structure. Other groups, such as memory and operation features, have smaller effects, indicating that the model can compensate for them through learned relational reasoning. Overall, the results highlight complementary nature of our feature design and the robustness of PROFIX when features are partially removed.

---

Table Parameter
sarcheter-matched matched comparison of baselines. All models have comparable parameter counts (~~ 1.67M) and are trained for the same number of epochs. Results are reported in overlap (%).
Model
#Params (M)
Train Time (slepoch)
Inference Time (ms/sample)
Overlap (%)
LSTM
1.68
2.14
0.97
85.42
GIN
1.68
0.69
1.03
78.76
GAT
1.65
0.81
1.92
83.79
GraphSAGE
1.68
0.75
1.12
88.97
GraphGPS
1.67
1.39
1.97
89.31
DAGNN
1.66
1.29
86.54
PROFX
1.67
1.33
1.72
93.50
Overall, the ablation results validate the effectiveness of our hierarchical design. The full model achieves the best performance across benchmarks, underscoring the importance of jointly modeling both CFG structure and sequential execution order for accurate profile inference.
4.6 Controlled Compute and Parameter Scaling for Baselines
In order to further control for the impact of model capacity and computational cost, conducted an additional set of experiments in which all baselines were adjusted to have approximately the same number of parameters (~ 1.67M), the results summarized in Table Each baseline model was first trained using the hyperparameter settings recommended by its original authors, which are widely recognized optimal near-optimal for the respective architectures.
Overall, our method consistently outperforms baselines even under strietly controlled compute and parameter budgets. These results indicate that the observed performance gains stem from the architectural design and inductive reasoning capability our model, rather than from increased model size computational advantage.
4.7 Performance on Real-World Applications
To evaluate the inductive generalization capability of our model, we measure profile inference accuracy on the diverse SPEC CPU 2017 benchmarks, which feature a wide range of control-fior complexities, function sizes. and execution patterns. As shown in Table our model consistently outperforms all baselines across benchmarks, achieving up to 98.85% profile accuracy on imagick, 96.26% on mef, and 95.83% on perlbench. It shows particular strength on structured control-flow workloads like parset and leela, where traditional GNNs and LSTM struggle to deal with. Overall, PROFIX improves overlap by up to 9.15% over Profi and achieves an average 6.26% improvement over other ML baseline models, highlighting the effectiveness of our model design.
4.8 Impact on Downstream Compiler Optimizations
To demonstrate the practical benefits of improved profile inference, integrate our profile inference model into the LLVM profile-guided optimization pipeline. We evaluate the performance improve- ments of PGO on MySQL by using profiles inferred by our model, compared raw sumpling-bssee and Profi-inferred profiles. Incorporating our refined profiles, the PGO-optimized binary achieves 12.1 01...%% average speedup over the native binary, while raw profiles only yield an ( 0.1%) speedup, and Profi-inferred profiles result in ( 0.3%) speedup. We run MySQL benchmarks multiple times ensure these results are within 95% confidence interval under t-distribution (28] These results highlight the effectiveness of PROFIX in enhancing PGO performance.
5 Conclusion
This paper presents PROFX, novel graph neural network (GNN)-based model and framework to improve the profile inference accuracy for sampling- campling-based profile- guilee optimization (PGO) in compilers. Comprehensive experiment results on real-world benchmark applications demonstrate that our GNN-based model achieves significant improvements over both state-of-the traditional algorithms and baseline machine learning models. These results demonstrate the superiority of PROFIX in improving the performance of sampling-basee based PGO and compiler optimization.
10

---

Acknowledgments and Disclosure of Funding
We thank the anonymous reviewers for their insightful and helpful comments. This work was supported in part by the Hong Kong Research Grants Council (Project No. 26216025) and the Alibaba Group (through the Alibaba Innovative Research Program). The views expressed in this work are those of the authors and do not necessarily reflect the views of the funding agencies.
References
[1] Aho Alfred, Lam Monica, and D Ullman Jeffrey. Compilers principles, techniques & tools. pearson Education, 2007.
[2] Amir Hossein Ashouri, Giovanni Mariani, Gianluca Palermo, Eunjung Park, John Cavazos, and Cristina Silvano. Cobayn: Compiler autotuning framework using bayesian networks. ACM Transactions on Architecture and Code Optimization (TACO), 13(2)1-25, 2016.
[3] Yunsheng Bai, Atefch Sohrabizadch, Yizhou Sun, and Jason Cong. Improving gnn-based accelcrator design automation with meta learning. In Proceedings of the 59th ACM/IEEE Design Automation Conference, pages 1347-1350, 2022.
[4] Maximilian Beck, Korbinian Pöppel, Markus Spanring, Andreas Auer, Oleksandra Prudnikova, Michael Kopp, Günter Klambauer, Johannes Brandstetter, and Sepp Hochreiter. xlstm: Extended long short-term memory. arXiv preprint wrxiv22405.05517, 2024.
[5] David Bieber, Charles Sutton, Hugo Larochelle, and Daniel Tarlow. Learning to execute pro- grams with instruction pointer attention graph neural networks. Advances in Neural Information Processing Systems, 33:8626-8635 2020.
[6] Alexander Brauckmann, Andrés Goens, Sebastian Ertel, and Jeronimo Castrillon. Compiler- based graph representations for deep learning models of code. In Proceedings of the 29th International Conference on Compiler Construction, pages 201-211, 2020.
[7] Brad Calder, Dirk Grunwald, Michael Jones, Donald Lindsay, James Martin, Michael Mozer, and Benjamin Zorn. Evidence-based static branch prediction using machine learning. ACM Transactions on Programming Languages and Systems (TOPLAS), 19(1):188-22 222, 1997.
[8] Dehao Chen, David Xinliang Li, and Tipp Moseley. Autofdo: Automatic feedback-directed optimization for warehouse- applications. In Proceedings of the 2016 International Symposium on Code Generation and Optimization, pages 12-23, 2016.
[9] Junjie Chen, Ningxin Xu, Peiqi Chen, and Hongyu Zhang. Efficient compiler autotuning via bayesian optimization. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), pages 1198-1209, IEEE, 2021.
[10] Li Chen, Rasmus Kyng, Yang Liu, Richard Peng, Maximilian Probst Gutenberg, and Sushant Sachdeva. Maximum flow and minimum-cost flow in almost-linear time. Journal of the ACM, 2022.
[11] Paul DuBois. MySQL. Addison- Wesley, 2013.
[12] Jad El Karchi, Hanze Chen, Ali TehraniJamsaz, Ali Jannesari, Mihail Popov, and Emmanuelle Saillard. Mpi errors detection using gan embedding and vector embedding over llvm ir. In 2024 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pages 595-607. IEEE, 2024.
[13] Kevin Gaffney, Martin Prammer, Larry Brasfield, Richard Hipp, Dan Kennedy, and Jignesh M Patel. Sqlite: past, present, and future. Proceedings of the VLDB Endowment, 15(12), 2022.
[14] Philip B Gibbons and Steven S Muchnick. Efficient instruction scheduling for a pipelined architecture. In Proceedings of the 1986 SIGPLAN symposium on Compiler construction, pages 11-16, 1986.
[15] Justin Gilmer, Samuel S Schoenholz, Patrick F Riley, Oriol Vinyals, and George E Dahl. Neural message passing for quantum chemistry. International conference on machine learning, pages 1263-1272. PMLR, 2017.

---

[16] M. Gori, G. Monfardini, and F. Scarselli. A new model for learning in graph domains. In Proceedings. 2005 IEEE International Joint Conference on Neural Networks, 2005., volume pages 729-734 vol. 2, 2005.
[17] Zhiyuan Guo, Zijian He, and Yiying Zhang. Mira: A program-behavior-guidedd far memory system. In Proceedings of the 29th Symposium on Operating Systems Principles, pages 692-708, 2023.
[18] Finn Hackett, Shayan Hosseini, Renato Costa, Matthew Do, and Ivan Beschastnikh. Compiling distributed system models with pgo. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, pages 159-175, 175, 2023.
[19] William I.. Hamilton, Rex Ying, and Jure Leskovee. Inductive representation learning on large graphs. In Proceedings of the st International Conference on Neural Information Processing Systems, NIPS 17, page 1025-1035, Red Hook, NY, USA, 2017. Curran Associates Inc.
[20] Wenlei He, Julián Mestre, Sergey Pupyrev, Lei Wang, and Hongtao Yu. Profile inference revisited. Proc. ACM Program. Lang., 6(POLL), January 2022.
[21] Wenlei He, Hongtao Yu, Lei Wang, and Taewook Oh. Revamping sampling-base -bsed pgo with context-sensitivity and secudo-instumennttion In 2024 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), pages
IEEE, 2024.
[22] Sepp Hochreiter and Jürgen Schmidhuber. Long short-term memory. Neural Comput.. 9(8):1735-178) November 1997.
[23] Saba Jamilan, Tanvir Ahmed Khan, Grant Ayers, Baris Kasikci, and Heiner Litz. Apt-get: Profile-guided timely software prefetching. In Proceedings of the Seventeenth European Conference on Computer Systems, pages 747-764, 2022.
[24] Tanvir Ahmed Khan, Dexin Zhang, Akshitha Sriraman, Joseph Devietti, Gilles Pokam, Heiner Litz, and Baris Kasikei. Ripple: Profile-guided instruction cache replacement for data center ap- plications. In 2021 ACM/IEEE 48th Anmual International Symposium on Computer Architecture (ISCA), pages 734-747. IEEE, 2021.
[25] Minsu Kim, Jeong- Keun Park, and Soo-Mook Moon. Solving pbqp-based register allocation using deep reinforcement learning. In 2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), pages 1-12. IEEE, 2022.
[26] Thomas N. Kipf and Max Welling. Semi-supervised classification with graph convolutional networks. In International Conference on Learning Representations, 2017.
[27] Sameer Kulkarni and John Cavazos. Mitigating the compiler optimization phase-ordering problem using machine learning. In Proceedings of the ACM international conference on Object oriented programming systems languages and applications, pages 147-162, 2012.
[28] Kenneth L Lange, Roderick JA Little, and Jeremy MG Taylor. Robust statistical modeling using the distribution. Journal of the American Statistical Association, 84(408):881-89) 1989.
[29] Chris Lattner. LLVM and Clang: Next generation compiler technology. In The BSD conference, volume 5, pages 1 1-20, 2008
[30] Chris Lattner and Vikram Adve. LLVM: A compilation framework for lifelong program analysis transformation. In International symposium on code generation and optimization, 2004. CGO 2004., pages 75- IEEF, 2004.
[31] Roy Levin, Ilan Newman, and Gadi Haber. Complementing missing and inaccurate profiling using minimum cost circulation algorithm. In Per Stenström. Michel Dubois, Manolis Katevenis, Rajiv Gupta, and Theo Ungerer, editors, High Performance Embedded Architectures and Compilers, pages 291-304, Berlin, Heidelberg, 2008 Springer Berlin Heidelberg.
[32] Shangyu Li, Juyong Jiang, Tiancheng Zhao, and Jiasi Shen. Osvbench: Benchmarking lims on specification generation tasks for operating system verification. arXiv preprint arXiv:2504.2096, 2025.
[33] Shangyu Li, Zhaoyang Zhang, Sizhe Zhong, Diyu Zhou, and Jiasi Shen. sound static analysis approach to i/o api migration. Proc. ACM Program. Lang., 900PSLA2) October 2025.
12

---

[34] Shuangli Li, Jingbo Zhou, Tong Xu, Liang Huang, Fan Wang, Haoyi Xiong, Weili Huang, Dejing Dou, and Hui Xiong. Structure-awe aware interactive graph neural networks for the prediction of protein-ligand binding affinity. In Proceedings of the 27th ACM SIGKDD conference on knowledge discovery & data mining. pages 975-985, 2021.
[35] Tianyang Liu, Qi Tian, Jianmin Ye, LikTung Fu, Shengchu Su, Junyan Li, Gwok- Swok-Waa Wan, Layton Zhang, Sam-Zaak Wong, Xi Wang, et al. Chatchisel: Enabling agile hardware design with large language models. In 2024 2nd International Symposium of Electronics Design Automation (ISEDA), pages 710-716. IEEE, 2024.
[36] Weijie Liu, Ximeng Liu, Zhi Li, Bin Liu, Rongwei Yu, and Lina Wang. Retrofitting lbr profiling to enhance virtual machine introspection. IEEE Transactions on Information Forensics and Security, 17:2311 11:2311-332,, 2022.
[37] Rahim Mammadli, Marija Selakovic, Felix Wolf, and Michael Pradel. Learning to make compiler optimizations more effective. In Proceedings of the Sth ACM Internation Symposium Machine Programming, pages 9-20, 2021.
[38] Charith Mendis. Alex Renda, Saman Amarasinghe, and Michael Carbin. Ithemal: Accurate. portable and fast basic block throughput estimation using deep neural networks. In International Conference on machine learning, pages 4505-4515, PMLR, 2019.
[39] Andy Newell and Sergey Pupyrev. Improved basic block reordering. IEEE Transactions on Computers, 69(12):184-1194, 2020.
[40] Diego Novillo. Samplepgo-the power of profile guided optimizations without the usability burden. In 2014 L.VV Compiler Infrastructure in HPC, pages 22-28. IEEE, 2014.
[41] Maksim Panchenko, Rafael Auler, Bill Nell, and Guilherme Ottoni. Bolt: practical binary optimizer for data centers and beyond. In 2019 IEEE/ACM International Symposium on Code Generation and Optimization (CGO), pages 2-14. IEEE, 2019.
[42] Maksim Panchenko, Rafael Auler, Laith Sakka, and Guilherme Ottoni. Lightnngg bolt: powerful. fast, and scalable binary optimization. In Proceedings of the 30th ACM SIGPLAN International Conference on Compiler Construction, pages 119-130, 2021.
[43] Kexin Pei, Weichen Li, Qirui Jin, Shuyang Liu, Scott Geng, Lorenzo Cavallaro, Junfeng Yang, and Suman Jana. Exploiting code symmetries for learning program semantics. In Forty-first International Conference on Machine Learning. 2024.
[44] Dinglan Peng, Shuxin Zheng, Yatao Li, Guolin Ke, Di He, and Tie-Yan Liu. How could neural networks understand programs? International Conference on Machine Learning, pages 8486. PMLR, 2021.
[45] Ladislav Rampášek, Michael Galkin, Vijay Prakash Dwivedi, Anh Tuan Luu, Guy Wolf, and Dominique Beaini. Recipe for a general, powerful, scalable graph transformer. Advances in Neural Information Processing Systems, 35: 15501-14555, 2022.
[46] Vivek Sarkar. Optimized unrolling of nested loops. In Proceedings of the 14th international conference on Supercomputing, pages 153-166, 2000.
[47] Jiasi Shen, Martin Rinard, and Nikos Vasilakis. Automatic synthesis of parallel unix commands and pipelines with kumquat. In Proceedings of the 27th ACM SIGPLAN Symposium Principles and Practice of Parallel Programming, PPoPP '22, page 431 1322 New York, NY, USA, 2022. Association for Computing Machinery.
[48] Jiasi Shen and Martin C. Rinard. Using active learning to synthesize models of applications that access databases. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2019, page 269-283 New York, NY, USA, 2019.
Association for Computing Machinery.
[49] Atefeh Sohrabizadeh, Yunsheng Bai, Yizhou Sun, and Jason Cong. Automated accelerator optimization aided by graph neural networks. In Proceedings of the 59th ACM/IEEE Design Automation Conference, pages 55-60, 2022.
[50] Richard M Stallman et al. Using and porting the GNU compiler collection, volume 86. Free Software Foundation Boston, MA, USA, 1999.
[51] Mark Stephenson, Saman Amarasinghe, Martin Martin, and Una-May O' O'Reilly. Meta optimiza- tion: Improving compiler heuristies with machine learning. ACM sigplan notices, 38(5):77-90. 2003.
13

---

[52] Ali TehraniJamsaz, Quazi Ishtiaque Mahmud, Le Chen, Nesreen K Ahmed, and Ali Jannesari. Perfograph: numerical aware program graph representation for performance optimization and program analysis. Advances in Neural Information Processing Systems, 36:57783-5777
2023. [53] Ali TehraniJamsaz, Mihail Popov, Akash Dutta, Emmanuelle Saillard, and Ali Jannesari. Learning intermediate representations using graph neural networks for numa and prefetchers optimization. In 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS), pages 1216-1216. IEEE, 2022.
[54] Joerg Thalheim, Pramod Bhatotia, and Christof Fetzer. Inspector: data provenance using intel processor trace (pt). In 20/6 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), pages 25-34. IEEE, 2016.
[55] Theodoros Theodoridis, Tobias Grosser, and Zhendong Su. Understanding and exploiting optimal function inlining. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, pages 977-989, 2022.
[56] Veronika Thost and Jie Chen. Directed acyclic graph neural networks. arXiv preprint arXiv:2101.07965, 2021.
[57] Jan Van Den Brand, Li Chen, Rasmus Kyng, Yang P Liu, Richard Peng, Maximilian Probst Gutenberg, Sushant Sachdeva, and Aaron Sidford. A deterministic almost-linear time algorithm for minimum-cost flow. In 2023 IEEE 64th Annual Symposium on Foundations of Computer Science (FOCS), pages 503-514, IEEE, 2023.
[58] Petar Veličković, Guillem Cucurull, Arantxa Casanova, Adriana Romero, Pietro Liò, and Yoshua Bengio. Graph attention networks. In International Conference on Learning Representations, 2018.
[59] S VenkataKeerthy, Siddharth Jain, Anilava Kundu, Rohit Aggarwal, Albert Cohen, and Ramakr- ishna Upadrasta. R14real: Reinforcement learning for register allocation. Proceedings of the 32nd ACM SIGPLAN International Conference on Compiler Construction, pages 133-144, 2023.
[60] Xi Wang. Gwok-War Wan, Sam-Zaak Wong, Layton Zhang, Tianyang Liu, Qi Tian, and Jianmin Ye. Chatepu: An agile cpu design and verification platform with 11m. In Proceedings of the 6lst ACM/IEEF Design Automation Conference, pages 1-6, 2024.
[61] Zheng Wang and Michael O' Boyyle. Machine learning in compiler optimization. Proceedings of the IEEE 106(1 17:9-89-1900 2018
[62] Youfeng Wu and James R Larus. Static branch frequency and program profile analysis. In Proceedings of the 27th annual international symposium on Microarchitecture, pages 1-11, 1994.
[63] Canran Xiao et al. Confusion-resistant federated learning via diffusion -aaed data harmonization on non-iid data. Advances in Neural Information Processing Systems, 37:137495-1377 1335520,, 2024.
[64] Keyulu Xu, Weihua Hu, Jure Leskovec, and Stefanie Jegelka. How powerful are graph neural networks? In International Conference on Learning Representations, 2019.
[65] Xiaojun Xu, Chang Liu, Qian Feng, Heng Yin, Le Song, and Dawn Song. Neural network-basee graph embedding for cross pooss-platfom binary code similarity detection. In Proceedings of the 2017 ACM SIGSAC conference computer and communications security, pages 363-376, 2017.
[66] Jiawei Yao, Chuming Li, and Canran Xiao. Swift sampler: Efficient learning of sampler by 10 parameters. Advances in Neural Information Processing Systems, 0.755000-59055 2024.
[67] Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. Devign: Effective vulnerability identification by learning comprehensive program semanties via graph neural networks. Advances in neural information processing systems, 32, 2019.
[68] Mingxuan Zhu, Dan Hao, and Junjie Chen. Compiler autotuning through multiple-phant learning. ACM Transactions Software Engineering and Methodology, 33(4):1-38, 2024.
14

---

under-will reduce the A Overlap Metric
To evaluate the quality of predicted execution profiles, we adopt the overlap metric, a widely used evaluation measure in prior work [20]. Overlap quantifies how well the predicted execution frequency distribution aligns with the ground truth. formally defined as:
Eiey min(f. ffree forcd)
Overlap
(11)
Eiev 1TD
where fiue and S denote the normalized execution frequencies of basic block in the ground truth and predicted profiles, respectively.
This metric captures the intersection between predicted and actual execution distributions. An overlap score of indicates perfect prediction (i.e., f! = f! for all i), whereas a score of 0 indicates no alignment at all. Note that, because the numerator uses the minimum of f!ue and f! overestimating a block's s frequency does not artificially inflate the score.
To ensure that fered represents valid probability distribution, our model applies softmax layer across all basic blocks in each function:
pood 1,
where n is the number of basic blocks. This normalization constrains the model to distribute fixed amount of probability mass. As a result, increasing the predicted frequency for one block necessarily decreases the predicted frequency for others, which prevents arbitrary inflation of overlap scores.
We illustrate the overlap metric with a simple example. Suppose function contains three basic blocks, and the true normalized execution frequencies are:
ptmee [0.5, 0.3, 0.2).
Case A (Perfect Prediction):
foood [0.5, 0.3, 0.2]
overlap = 1.0
Case B (Overestimate BB,, Underestimate BB;):
forod [0.3, 0.5, 0.2]
overlap = 0.3 + 0.3 + 0.2 = 0.8
As seen above, although BB, is overestimated, the increase comes at the expense of BB1, whose prediction now lower than the ground truth. Because the overlap only accounts for the minimum between predicted and true values, misalignment in any direction- score.
In summary, the overlap metric provides meaningful and bounded measure of prediction quality. It encourages models to align with ground-truth distributions holistically, rather than simply boosting predictions for few hot blocks. Thanks to softmax normalization, our model inherently avoids degenerate solutions where predicted frequencies are uniformly inflated, ensuring that the overlap metric faithfully reflects profile inference accuracy.
B Model Complexity
We analyze the theoretical computational complexity of each major component in PROFIX, as summarized in Table 7 The LSTM layer has complexity of O(4NA² + dh),), where N is the number of basic blocks, is the input dimension, and h is the hidden size. This complexity accounts for the computation of four internal gates per time step.
For structural encoding, the GraphSAGE layer ineurs O(N + dB)) complexity, where average number of neighbors per node. Our SAGEAttennton layer combines attention-bass edge weighting and neighborhood aggregation, resulting in O(Ed + N(dd + d))), where F. denotes the number of edges.
15

---

The total complexity across all L stacked layers is approximately O(L (Nh + Ed + Nd))). reflecting the alternating design of LSTM and SAGEAttention blocks. This hybrid architecture strikes balance between expressiveness and scalability, making it feasible for large-scale control-flow graphs extracted from real-worle software.
Table Complexity of different model components.
Layer Type
Complexity
Comment
Every time step calculates 4 gates (input, forget. oulpul. candidate). sequence length is Neighbor aggregate N k and linear transformation N d
LSTM
O(4N4² + dh)
GraphSAGE
((N dP))
GAT attention calculation E and GraphSAGE ( + d)))
SAGEAttention
O(Ed+ N(kd +))
Every layer contains I.STM and SAGEAttention, layers, E O(kN)
Overall
O(L (NN2 Ed Nd)))
where
N is the number of nodes (basic blocks),
E is the number of edges,
d is the input dimension,
h is the hidden dimension LSTM,
k is the average number of neighbors in GraphSAGE,
L is the number of our SAGEAttention layers.
C Training Time Comparison
We report the training, validation, and inference time for PROFIX and baselines in Table Runtime is measured on a per-epoch basis for training and validation, and per-sample basis for inference. Among all methods, our model incurs the highest computational cost due its stacked architecture of LSTM and SAGEAttention layers. Despite this overhead, the training time remains under 1.5 seconds per epoch, and inference requires only 1.72 milliscconds per sample, making it suitable for offline optimization scenarios.
Table 8: Training, validation, and inference time comparison.
Training Time (Slepoch)
Validation Time (S/epoch)
Inference Time (ms/sample)
Model
Profi
N/A
N/A
16.12
LSTM
1.075
0,258
0.32
GCN
0.172
0.276
0.48
GraphSAGE
0,209
0.235
0.39
GIN
0.181
0.180
0.25
GAT
0.252
0.388
0.71
PROFIX
1.328
0.830
1.72
In terms of computational complexity. model combines the costs of recurrent and based modules. The LSTM contributes O(Nh?) per sequence, while the SAGEAttention layer-composed of GraphSAGE and GAT-adee O(Ed + N per graph layer, where N is the number of basic blocks, the number control-flor edges, the LSTM hidden size, and the embedding dimension. Given stacked layers, the total forward-pat passs complexity becomes O(L (Nh + Ed Nd))). Although this hybrid design introduces greater computational cost, it yields significantly improved accuracy, shown in earlier evaluation.
As shown in the table, the traditional algorithm does not require training requires a longer inference time. This is due to the fact that it directly operates the internal data structures of
16

---

LLVM, which introduces extra execution time. On the other hand, PROFIX does require more training time compared to simpler machine learning models like LSTM or GraphSAGE. However, the additional time investment leads to significant improvements in the overall performance of the optimized binaries, as discussed Section 4.7 We attribute this difference the tradeoff between time and accuracy, where the additional training time enables the model to generate more accurate profiles, ultimately enhancing the effectiveness of profile-guided optimization.
D Hyperparameters
We summarize the key hyperparameters used during model training in Table The model is optimized using the Adam optimizer with an initial learning rate of 0,001, and StepLR scheduler is applied to gradually reduce the learning rate during training. The LSTM hidden size is set to 256, and we stack three SAGEAttention layers with a dropout rate of 0.1 for regularization. Training is performed with early stopping based on validation loss, using a patience of 10 epochs. We employ root mean square error (RMSE) as the loss function, and split the dataset into 80% training, 10% validation, and 10% testing. These choices balance performance and generalization while ensuring stable convergence across benchmarks.
Table 9: Key hyperparameters for model training.
Hyperparameter
Value
Learning Rate
0.001
Train Batch Size
128
Validate/Test Batch Size
1
Optimizer
Adam
Weight Decay
(No weight decay)
Learning Rate Scheduler
StepLR (Step Size: 5, Gamma: 0.97)
Epochs
300
LSTM Hidden Size
256
SAGE Attention Layers
3
Dropout Rate
0.1
Early Stopping Patience
10
Loss Function
RMSE Loss 80%, 10%, 10%
Moiin-Valddate-11 Test Split Ratio
E Key Features extracted from LLVM IR
Table 10 summarizes the key features we extracted from the LLVM IR code, based on the data collected during profiling and instrumentation. These features are essential for understanding the be- havior basic blocks in the functions being analyzed and for representing the program characteristics. Furthermore, the use of LLVM IR makes PROFIX agnostic to the source language.
In analysis, not only extract various instruction also consider the structural relationship between basic blocks by incorporating the features of their successors. This design enables capture how the control flow and branching behavior of program influence its execution patterns.
features from each basic block but
For each basic block (BB), the following features computed:
Successor Blocks: The set of successor blocks (or target blocks for branches) is considered a key feature of the current basic block. This feature important because the control flow from one basic block to another directly impacts the execution frequency and the optimization strategies employed by the compiler.
Successor Features: For each successor block of given basic block, we append its own feature vector represent the relationship between the current block and its successors. Specifically:
17

---

Table 10: Key features extracted from the LLVM IR.
Description
Feature Type
Fields
(Information Modeled)
phiNumber
Number PHI nodes (Models control dependencies)
successortNunber
Number of successors (branches) (Models control flow)
predeceasorllumber
Number of predecessors (Models control flow)
Control Flow
ieEntry
Flag indicating if the basic block the entry block (Models entry point) Flag indicating if the busic block exit block (Models exit point)
isErit
isLoopfleader
Flag indicating if the basic block is loop header (Models loop structure)
loadNluberr
Number of load instructions (Models memory read operations)
Memory Operations
storeNumber
Number store instructions (Models memory write operations)
gepäumber
Number GetElementPtr instructions (Models memory access)
instruct onnuuberr
Total number of instructions (Models overall memory instructions)
ari thmetitt timbbmber
Number of arithmetic operations (Models computational complexity)
Arithmetic and Logic
logicalNunee
Number of logical operations (Models computational complexity)
castllubber
Number cast instructions (Models type conversion)
callNumber
Number call instructions (Models function call behavior)
Call and Intrinsics
intrinaic/umber
Number of intrinsic function culls (Models specialized operations)
For conditional branches, the two successor blocks corresponding to the true and false branches are treated as two distinct features.
For unconditional branches, only the single successor block is considered.
For switch statements, each potential successor (case or default block) is included in the feature set, with the average feature vector being calculated across all case successors.
Feature Representation: The feature vector of each basic block includes the features of its immediate successors. This feature helps to model the impact of branching on the execution flow, where the behavior of a block's 's successors (such as their instruction count, branch direction, or loop presence) is critical for making predictions on the block's ' behavior and its contribution to the overall function execution.
The adjacency between basic blocks is stored set of features that reflect the program's 's control flow graph (CFG). This adjacency information is concatenated with the instruction-level features of the basic block to provide complete representation of the block in the context of its neighbors in the program's 's control flow. This feature includes the number of predecessors and successors, which informs the model about the block's position in the program's 's flow.
Adjacency Information:
F Limitations
While our approach demonstrates strong performance across a range of benchmarks, there are few limitations worth noting. First, the current model is trained and evaluated on statically compiled programs with well-defined control-flow graphs; applying the method to highly dynamic or just-in-time compiled workloads may require additional adaptations. Second, although our framework generalizes across multiple applications, domain-specift fine-tuning could further improve performance in specialized settings such as embedded systems or GPU kernels. Lastly, our evaluation primarily focuses on offline optimization scenarios; exploring integration with online or interactive profiling workflows remains an interesting direction for future work.
G Broader Impacts
Our work on enhancing compiler optimization through improved profile inference using Graph Neural Network (GNN)-based model has several broader impacts. First, by increasing the accuracy of profile data, our approach can lead the generation of more efficient binaries, potentially reducing energy consumption and computational costs across a wide range of applications. This is particularly significant given the growing environmental concerns associated with hiigh-performncce computing and data centers. Furthermore, the improved efficiency and performance of software may contribute to enhanced user experiences and enable more complex computational tasks to performed on existing hardware, extending the lifespan of devices and reducing electronic waste. However, the increased
18

---

efficiency and optimization capabilities also raise concerns about potential misuse. Optimized binaries could be used amplify the effectiveness of malicious software. making it more difficult detect and counteract. Therefore, our work underscores the importance of incorporating safety and ethical considerations into the development and deployment of compiler optimization technologies.
19

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification:
Abstract reports our main results and Section | flists our main contributions.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results
be expected to generalize other settings.
is fine to include aspirational goals as motivation as long is clear that these goals are not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations of the work performed by the authors?
Answer: [Yes]
Justification:
We discuss limitations in Appendix F
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification. asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution low or images are taken in low lighting. Or speech-to-text system might be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and faimess.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren't 't acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
20

---

This paper focuses on the design and evaluation of a learning based profile inference framework and does not include any theoretical results.
Justification:
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Question:
Answer: [Yes]
Justification: We present our model design in Section the experimental environment in Section 4 and hyperparameters in Appendix D
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurlPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
21

---

Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [No]
Justification:
We will share the code upon request.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips... cc.
hubblic//ulless/oddeSlbmm.ssss wtt.:/uwbmmiiiooooooooooooo for more details.
While we encourage the release of code and data, we understand that this might not be possible, "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurlPS code and data submission guidelines (https
/ //nips.co. ccpppi.ccppulli///ggg. guwdes/ddeeeee CooeeSumeeieeeeeeeeeee ssi onyolicy) for more details.
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data,
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Question:
Answer: [Yes]
Section 4 presents how we collect and preprocess the dataset, as well as the dataset split ratio during the training phase. Appendix [ lists the hyperparameters and optimizer we used in our experiments.
Justification:
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented the core the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [Yes]
Justification: Section 4 presents the statistics of our datasets. In the last Section 4.8 we run the benchmarks multiple times make sure the results are within 95% confidence interval.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by emoor bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
22

---

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not show in tables figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
error bars are reported in tables or plots, The authors should explain the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Question:
Answer: [Yes]
Justification: We present our experiment environment in Section 4 We present the training time comparison Appendix C
Guidelines:
The answer NA means that the paper does include experiments.
The paper should indicate type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (c.g., preliminary or failed experiments that didn't 't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurlPS Code of Ethics Ethics/https: httpp/////eeaaesssceccep////eeie
Answer: [Yes]
Justification:
The research conducted in the paper conforms to the NeurIPS code of ethics.
Guidelines:
The answer NA means that the authors have reviewed the NeurIPS Code of Ethics.
the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (c.g.. if there special consid- eration due to laws or regulations in their jurisdiction..
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification:
We discuss the impacts of our work in Appendix G
Guidelines:
The answer NA means that there is no societal impact of the work performed.
23

---

If the authors answer NA or No, they should explain why their work has no societal impact or why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), faimess considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: This paper poses no such risks.
Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards challenging, and many papers do not require this, but encourage authors to take this into account and make best. faith effort.
12. Licenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper. properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: We the Porch framework when implementing our model and baselines, cited in Section I and Section 4
Guidelines:
The answer NA means that the paper does existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset used and, possible, include a URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.
24

---

If assets are released, the license, copyright information, and terms of use in the thcode. has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
package should be provided. For popular datasets, datasets.papersstt paperswi
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
If this information is not available online, the authors encouraged to reach out the asset's s creators.
13. New assets
Question: Are assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: The new assets introduced in the paper well documented in our anonymous github repository at htttp:://annnmmonn 4open. sciince/r/pgo.....
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset is used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification:
This paper does not involve any experiments and research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then much detail as possible should be included the main paper.
According to the NeurlPS Code of Ethics, workers involved in data collection, curation, other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
This paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does involve crowdsourcing nor research with human subjects.
Depending the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
25

---

We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors adhere the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Question:
Answer: [NA]
Justification: The core method development in this research does involve LLMs as any important, original, or non-standard components.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, non-standard components.
Please refer to our LLM for what should or should not be described.
26


Reviews:
[{"review_id": "plEQMftqW8", "reviewer": "Reviewer_6WJt", "summary": "This paper describes a method of augmenting traditional sampling-based Profile Guided Optimization (PGO) with a neural network. The proposed neural network is a hybrid architecture alternating graph neural network (GNN) layers with long-short-term memory (LSTM) layers to capture both long-distance sequential execution paths and statically-defined control flow graphs extracted from the LLVM-IR code representation. The objective of the model is to accurately predict the real execution frequencies of basic blocks given the code CFG and noisy sampling data.", "questions": "1. Comparing the LSTM layers with other types of model architectures would be helpful to accurately evaluate the design reasoning. Using LSTM seems like an odd choice when there are more modern architectures available.", "limitations": "yes", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "The proposed model significantly improves profiling accuracy across a wide range of benchmarks and against both traditional symbolic profiling and several neural models. The paper performs ablation analysis to confirm their reasoning for the model architecture, even ablating the SAGEAttention layers. The model combines two primary neural network architectures in such a way as to cover each of their deficiencies; a strategy seldom seen. This paper represents a marked improvement in current neural-based profiling algorithms.", "was_revised": true, "final_justification": "Most of the concerns I had have been clarified by the authors. Including these clarifications in the paper will further improve it.", "rebuttal": "Thanks for your valuable feedback.\n\n> Using LSTM seems like an odd choice when there are more modern architectures available.\n\nWe chose LSTM for the following reasons:\n\n- Sequential patterns are critical for profile inference. In the context of control-flow graphs (CFGs), execution traces exhibit strong local sequential dependencies (e.g., hot paths, frequently co-executed blocks). LSTMs are well-suited for modeling such localized sequences and have a proven track record in learning from noisy temporal patterns, which aligns well with our task of inferring execution frequencies from sampled profiles.\n\n- Model simplicity and training stability. Compared to large-scale Transformers, LSTMs offer a favorable tradeoff between expressiveness and computational cost, especially in compiler optimization pipelines where inference speed and scalability are important.\n\nWe also conducted an experiment on replacing LSTM with other encoders, such as transformers. However, the results shows that replacing LSTM in our network leads to a performance downgrade of 1.4%. The possible reason is that the hot path is more like a sequence with dependence, which is more appropriate for LSTM to capture such pattern."}, {"review_id": "tQHCJP5oym", "reviewer": "Reviewer_EdtZ", "summary": "The paper tackles the established problem of profile inference: predicting execution frequencies of code blocks from noisy counts from a sampling profiler. It suggests a hybrid RNN-GNN architecture that operates on the program's control-flow graph to leverage both sequential and graph-based features of the code.\n\nIn the absence of machine learning baselines, several architectures are compared against each other and against a classical heuristics-based algorithm on data from the SPEC CPU 2017 benchmark. Moreover, integration into LLVM's profile-guided optimization leads to real-world speedups on the MySQL binary unmatched by the classical baseline method.", "questions": "0. Could you provide evaluation results on *un-contaminated* out-of-distribution benchmarks?\n1. How does the method compare to \"global attention\" methods such as graph transformers?\n2. How does the method compare to the baselines when they get more parameters as to match compute / runtime (cf. App C)?\n3. How important is the trick of using successor features in the node features?\n4. Which data preprocessing is used exactly? What is an \"inconsistent basic block structure\" (L225)? hich normalization is used exactly for execution counts (L226)?\n5. L293: It is unclear whether there are any ablations on the use of LSTMs in the hybrid layers (L194) or only of the first LSTM encoder (L169).\n\n**Minor:**\n\na) L178: Which aggregation function AGG is actually used in this work?\n\nb) L171: There is no topological ordering on a general CFG because it can have cycles. Which linearization is used?\n\nc) L131: Not familiar with the literature, but to my understanding, GraphSAGE is a standard message-passing network up to the fact that it uses a sampled subset of the neighborhood. What is the \"inductive learning framework\" that sets GraphSAGE apart?\n\nd) L150: DFGs aren't used in this work, correct?", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "**Strengths:**\n- The paper proposes a new way of applying machine-learning to compiler optimization.\n- The paper shows convincing results compared to the classical baseline on a random test-split of the collected data.\n\n**Weaknesses:**\n- The real-world use case MySQL (L322) was used in the training data (with ground-truth instrumentation based profiles available) (L214).\n- The remaining benchmarking happens on a random 10% test split of the collected data, meaning all evaluations are in-distribution. \n- Ablations do not carry much weight as they are not compute/time/parameter matched, favoring the hybrid architecture by design.\n- Ablations restrict themselves to architecture modifications, omitting the special feature engineering (using successor node features among the node's features).\n- The proposed hybrid RNN-GNN architecture is not well-positioned within a rich literature on such hybrid methods (e.g. DAGNNs).\n- Key baselines such as graph transformers are not considered.", "was_revised": true, "final_justification": "All major concerns have been addressed. The work solves a previously untackled problem with scores better than the non-neural baselines. The interaction between the special feature engineering and the modeling is poorly analyzed (with most of the paper focusing on the modeling while the feature engineering appears to be the most important contribution to benchmark performance, and it seems unlikely that features have been specifically optimized for the baselines too), but it remains an interesting datapoint for applied machine learning applied to compiler optimization and can have real-world impact.", "rebuttal": "First, we would like to thank you for your efforts in providing these insightful comments. However, we believe there may be a misunderstanding regarding our experimental setup.\n\n> The real-world use case MySQL (L322) was used in the training data (with ground-truth instrumentation based profiles available) (L214).\n\nThere is **no** data contamination in the real-word downstream speed-up evaluation of MySQL (L322) in section 4.7:\n\n- During training data collection (L214), we used `sysbench` to create a randomly generated database and executed read-write benchmark tests with a default access pattern to collect both sampled and ground-truth profiles.\n- During evaluation (L322), we generated a new random database by `sysbench` again, which is independent of the one used for training, and conducted a different class of read-write benchmark queries, with modified parameters (e.g., different read-write ratios, table sizes, and thread counts). Therefore, the hot path of the program and the collected sampled profile and its ground-truth is **totally differ from** the profile in training phase.\n\nThis setup ensures that the test profiles in L322 come from a **different** data distribution and are not seen during training.\n\n> The remaining benchmarking happens on a random 10% test split of the collected data, meaning all evaluations are in-distribution.\n\nIn our experiments, we have included an evaluation on in-distribution (Section 4.3, 4.4) and out-of-distribution data (Section 4.5, 4,6). The models were trained on 80% data of profiles collected from Clang 20.0, GCC 14.2, MySQL 8.32, and SQLite 3.\n\n**Table1.** \n\n| Phase | Source Program | Dataset Split| Results   |\n| ----| ---- | ---- | ---- |\n| Training and Testing (**in-distribution**)  | Clang 20.0, GCC 14.2, MySQL 8.32, SQLite 3 | 80% train, 10% validation, 10% test | Figure 4, 5 |\n| Evaluation on Real-World Apps (**out-of-distribution**) | SPEC CPU 2017 (unseen during training) | No split | Table 3, 4  |\n\n> Could you provide evaluation results on un-contaminated out-of-distribution benchmarks?\n\nOur evaluation conducted on uncontaminated and out-of-distribution benchmarks (Section 4.3-4.6):\n\n1. MySQL evaluation scenario is disjoint from MySQL training data, we ensure complete it is **un-contaminated**:\n2. Evaluation on Real-World Apps (SPEC CPU 2017) is entirely **out-of-distribution** (see Section 4.5, 4.6).\n\n> Ablations do not carry much weight as they are not compute/time/parameter matched, favoring the hybrid architecture by design.\n\nOur ablation study in Table 3 in the paper is designed to evaluate the importance of both **component and architecture alternatives** -- they are presented together in a single unified table for conciseness.\n\n- The first column in each group (e.g., “w/o LSTM”, “w/o GNN”, “w/o SAGE”) represents **component ablations**, where a component is removed entirely while keeping the rest of the architecture unchanged. These reflect the importance of each component in our model.\n- The other columns (e.g., “w/ GRU”, “w/ GAT”, “w/ SAGE”) represent **architecture ablations**, where the removed component is replaced with a similarly-sized alternative (e.g., GRU for LSTM, GCN for GraphSAGE) to ensure the effectiveness of our model component design.\n\n\n> Ablations restrict themselves to architecture modifications, omitting the special feature engineering (using successor node features).\n\nWe conducted experiments on SPEC CPU 2017 where we removed groups of input features described in Appendix E to assess their impact on model performance. We categorized the input features into five groups:\n\n1). Successor features, where each basic block’s input vector is augmented with its successors’ features,\n\n2). Control-flow features (e.g., number of predecessors/successors, loop headers),\n\n3). Memory operation counts (load/store/gep),\n\n4). Arithmetic and logic operations,\n\n5). Call and intrinsic counts.\n\n**Table 2.**\n\n| **Feature Group Removed** | **Overlap (%)** | **RMSE** | **$\\Delta$ Overlap vs Full Model** |\n| ---- | ---- | ---- | ---- |\n| **None (Full Model)** | **93.42** | 0.034 | —   |\n| 1)                        | 90.06           | 0.044    | ↓ **3.36**                         |\n| 2) | 91.32  | 0.039 | ↓ 2.10  |\n| 3) | 92.21 | 0.037 | ↓ 1.21 |\n| 4) | 91.14 | 0.041 | ↓ 2.28 |\n| 5) | 92.65  | 0.036 | ↓ 0.77  |\n\nThe results show that removing successor features leads to the largest drop in accuracy, indicating their critical role in modeling data/control dependencies. Control-flow and memory features also contribute meaningfully, while removing compute or call features has more moderate impact.\n\n\n> The proposed hybrid RNN-GNN architecture is not well-positioned within a rich literature on such hybrid methods (e.g. DAGNNs).\n\nWe report more baselines results such as DAGNN and GraphGPS (Graph Transformer) on the test set:\n\n**Table 3.**\n\n| Model  | RMSE | Overlap (%) | Inference Time (ms/sample) |\n| ----- | ---- | ---- | ---- |\n| LSTM  | 0.055  | 88.70  | 0.32  |\n| GCN | 0.098  | 80.50  | 0.48 |\n| GIN | 0.104 | 79.30   | 0.25 |\n| GAT | 0.063  | 86.20  | 0.71 |\n| GraphSAGE   | 0.045  | 90.30  | 0.39 |\n| ***GraphGPS**  | 0.058  | 89.42   | 0.91 |\n| ***DAGNN**  | 0.061  | 87.95  | 0.66 |\n| **Ours (Full)** | **0.034** | **93.50**   | 1.72 |\n\nThe difference between our model and DAGNNs is as follows:\n\n1. Our method was motivated by the unique challenges of profile inference over control-flow graphs (CFGs), which combine both sequential execution traces (captured by sampled profiles) and structured control dependencies (captured by CFG topology).\n\n2. While DAGNNs and related models operate over acyclic graphs and often focus on semantic code tasks (e.g., program classification or summarization), our task and method is distinct in that the input CFGs may **contain cycles**, especially due to loops and backedges, which are fundamental in compiler IR. This makes classical DAG-only models less directly applicable.\n\n> Key baselines such as graph transformers are not considered.\n\nThe result of GraphGPS (graph transformer) presented in the Table 3. above.\n\n\n> How does the method compare to 'global attention' methods such as graph transformers?\n\nWe compared graph transformers (GraphGPS) with our method (see Table 3. above). The experiment results show that graph transformers underperforms compared to our proposed hierarchical model, likely due to the lack of inductive bias toward sequential - execution patterns, which are crucial in sampled profile reconstruction.\n\n\n> How important is the trick of using successor features in the node features?\n\nThe ablation study of node features (see Table 2. above) shows that using successor features in the node features brings a significant performance improvement (3.36%), demonstrating its effectiveness in solving the profile inference problem.\n\n> Which data preprocessing is used exactly? What is an \"inconsistent basic block structure\" (L225)? Which normalization is used exactly for execution counts (L226)?\n\n1. We exclude functions with extremely sparse sampling (< 2 BBs) due to lack of meaningful learning signal. We align functions one‑to‑one by symbol name, source file path, and signature hash, and use consistent LLVM IR and CFG extraction.\n\n2. When collecting profiles using sampling (perf) and ground-truth instrumentation, the binaries are compiled separately, and the compiler’s optimization passes (e.g., inlining, loop unrolling) are heuristic and nondeterministic. As a result, the same source-level function may be compiled into different basic block (BB) structures across the two versions. In such cases, it becomes impossible to reliably align sampled and instrumented BB-level profiles.\n\n3. We apply L1 normalization.\n\n> It is unclear whether there are any ablations on the use of LSTMs in the hybrid layers or only of the first LSTM encoder.\n\nThe ablations are performed on the LSTMs used in the hybrid layers and the initial LSTM encoder. Removing the LSTM affects all hybrid layers in the stacked architecture and the encoder, which leads to a performance drop (93.42 to 92.70) in accuracy, as shown in Table 3 in paper.\n\n> Which aggregation function AGG is actually used in this work?\n\nWe used average pooling as the aggregation function AGG.\n\n> There is no topological ordering on a general CFG because it can have cycles. Which linearization is used?\n\n\nWhile general CFGs can contain cycles (e.g., due to loops), a well-established approach [1] is to use Reversed Post Order (RPO) traversal, which is commonly used in compilers as a generalization of topological order for graphs with cycles. Therefore, we used RPO as linearization in this work.\n\n> What is the 'inductive learning framework' that sets GraphSAGE apart?\n\n\nGraphSAGE is considered as an inductive learning framework [2] because it learns an aggregation function that generalizes to unseen nodes and graphs during inference, without requiring access to the full training graph at test time.\n\n> DFGs aren't used in this work, correct?\n\nOur approach leverages DFG-relevant signals as part of the node-level input representation, allowing the model to reason over both control and data aspects of program execution. In particular:\n\n- Our input features (Appendix E) include memory-related operations, which reflect data movement and access patterns.\n- The inclusion of phiNumber captures control-dependent value merging, a key aspect of SSA-form data flow.\n- Our successor features aggregate information from downstream basic blocks, which often carry data-use context, helping the model understand flow-sensitive behavior.\n- Instruction counts and call patterns also encode semantic-level data dependencies at the basic block level.\n\n[1] Cooper K D, Torczon L. Engineering a compiler[M]. Morgan Kaufmann, 2022.\n\n[2] Hamilton W, Ying Z, Leskovec J. Inductive representation learning on large graphs[J]. Advances in neural information processing systems, 2017, 30."}, {"review_id": "ZgNgRV9inw", "reviewer": "Reviewer_d7mA", "summary": "This paper addresses the problem of profile inference for sampling-based Profile-Guided Optimization (PGO) in compilers. The authors propose a novel Graph Neural Network (GNN)-based model to correct inaccuracies (underestimation, overestimation, missing data) in execution profiles collected through hardware sampling. The model processes the program's Control-Flow Graph (CFG), using a combination of LSTMs to capture sequential execution patterns and a custom \"SAGEAttention\" layer to model structural dependencies. The authors present an end-to-end framework integrated with the LLVM toolchain. They evaluate their approach on a diverse set of benchmarks, including SPEC CPU 2017, and show that their model outperforms a state-of-the-art traditional algorithm (Profi) and several baseline machine learning models in terms of profile accuracy (Overlap metric) and downstream performance gains on an optimized MySQL binary.", "questions": "- Can the authors further justify the speed up. For a large code base, what percentage of total build time does profile inference add, and is it amortized over multiple builds?\n- Your framework is built on LLVM. How much of the feature engineering and overall approach is tied to the LLVM IR? What would be the main challenges in adapting this method to a different compiler ecosystem, such as GCC?", "limitations": "The authors have discussed limitations", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 2, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Strengths:\n\n- The model plugs into LLVM without modifying internals and supports both static and post-link optimization, demonstrating a clear path to deployment.  \n- The paper is clear and easy to follow.\n\nWeaknesses:\n\n- The core weakness is the limited novelty of the model architecture itself. The proposed \"SAGEAttention\" layer is a combination of existing, well-established components (GraphSAGE, GAT, LSTMs, and residual connections). As for the application to profile inference, using GNN has already been discussed in [1][2].\n- Empirical study only considered very limited amount of baselines.\n\n[1] Phothilimthana, Mangpo, et al. \"Tpugraphs: A performance prediction dataset on large tensor computational graphs.\" Advances in Neural Information Processing Systems 36 (2023): 70355-70375.\n\n[2] Cao, Kaidi, et al. \"Learning large graph property prediction via graph segment training.\" Advances in neural information processing systems 36 (2023): 23345-23361.", "was_revised": true, "final_justification": "While I still have some minor concerns regarding the distinction between this work and prior efforts that also apply GNNs to programs, I am overall comfortable recommending acceptance of the paper.", "rebuttal": "We thank the reviewer for the thoughtful feedback.\n\n\n\n> The core weakness is the limited novelty of the model architecture itself. The proposed 'SAGEAttention' layer is a combination of existing components (GraphSAGE, GAT, LSTMs, residual connections).\n\nThis work **first** proposed a GNN-based learning method to solves the under-explored task of **profile inference** for compiler optimization is both original and effective.\n\nThe novelty of our work lies not in inventing entirely new primitives, but in the task-specific integration and architectural design tailored to the unique demands of profile inference over control-flow graphs (CFGs). Specifically:\n\n- **Novel model design driven by compiler-specific challenges.** Unlike graph learning tasks, profile inference requires modeling both the dynamic execution order (often noisy and incomplete due to sampling) and the static control-flow structure of a program. To address this, we propose a hierarchical architecture that alternates between LSTM-based sequential modeling and structure-aware GNN layers. \n\n- **The SAGEAttention layer as a domain-specific integration.** Our SAGEAttention layer is not a naive stacking of GraphSAGE and GAT, but a carefully constructed hybrid that retains GraphSAGE’s inductive generalization with attention-based contextual refinement, followed by residual feedforward transformation and normalization. It serves as a drop-in module that integrates both structural and sequential representations in CFG and profile pattern.\n\n- **Enabling generalization and PGO impact.** Our model demonstrates strong inductive generalization across applications (e.g., SPEC, MySQL), and yields real performance gains in downstream PGO workflows, which prior symbolic or ML models fail to achieve. We believe this demonstrates architectural novelty in service of solving a real compiler problem.\n\n\n\n\n\n> The empirical study only considered very limited amount of baselines.\n\nWe report more representative baselines results such as DAGNN and GraphGPS (Graph Transformer) on test set:\n\n| Model           | RMSE      | Overlap (%) | Inference Time (ms/sample) |\n| --------------- | --------- | ----------- | -------------------------- |\n| LSTM            | 0.055     | 88.70       | 0.32                       |\n| GCN             | 0.098     | 80.50       | 0.48                       |\n| GIN             | 0.104     | 79.30       | 0.25                       |\n| GAT             | 0.063     | 86.20       | 0.71                       |\n| GraphSAGE       | 0.045     | 90.30       | 0.39                       |\n| ***GraphGPS**   | 0.058     | 89.42       | 0.91                       |\n| ***DAGNN**      | 0.061     | 87.95       | 0.66                       |\n| **Ours (Full)** | **0.034** | **93.50**   | 1.72                       |\n\n> As for the application to profile inference, using GNN has already been discussed in [1] [2].\n\nWhile both [1] (TpuGraphs) and [2] (Graph Segment Training) involve GNNs applied to program or graph data, neither of them addresses the task of profile inference.\n\n1. TpuGraphs is a benchmark dataset for execution time prediction of large computational graphs on TPUs. It focuses on regression of runtime given tensor programs, not on predicting control-flow behavior like basic block execution frequencies.\n2. Graph Segment Training is a general framework for scalable graph-level property prediction. It **does not** focus on compiler applications, nor on learning instruction-level control-flow profiles.\n\nIn contrast, our work is the **first** to propose GNN-based learning for basic block-level profile inference, aiming to replace expensive instrumentation-based profiling in production compilers. We model fine-grained execution frequencies over dynamic control flow, which is a different task from the graph-level classification or regression in [1, 2].\n\n\n\n> What percentage of total build time does profile inference add, and is it amortized over multiple builds?\n\nProfile inference adds approximately 3–5% overhead to the total build time in a typical profile-guided optimization (PGO) pipeline when applied to medium- to large-scale projects such as MySQL. This includes the time for:\n\n- Control-flow graph (CFG) features extraction from LLVM IR,\n- Batched model inference (on GPU or CPU),\n- Writing inferred profiles back to disk in the compiler’s expected format.\n\nImportantly, this inference step is lightweight and runs entirely offline, typically taking under 2 seconds for a binary with thousands of functions (as shown in Section 4, Table 6).\n\n\n\n> Your framework is built on LLVM. What would be the main challenges in adapting this method to GCC?\n\nOur proposed methodology is not LLVM-specific. Adapting the framework to GCC would mainly involve:\n\n- Extracting control-flow graphs (CFGs) and corresponding basic block-level features from GCC’s internal GIMPLE or RTL IR representations;\n\n- Mapping sampled/instrumented profiles back to these basic blocks in a consistent and reliable way;\n\n- Ensuring compatibility with GCC’s profile format and optimization pipeline for downstream PGO.\n\n\nThese are mostly engineering and tooling challenges, not algorithmic ones. Given access to the necessary CFG and profile interfaces, our model can be retrained on GCC-generated IR with minimal architectural change.\n\n\n\n[1] Phothilimthana, Mangpo, et al. \"Tpugraphs: A performance prediction dataset on large tensor computational graphs.\" Advances in Neural Information Processing Systems 36 (2023): 70355-70375.\n\n[2] Cao, Kaidi, et al. \"Learning large graph property prediction via graph segment training.\" Advances in neural information processing systems 36 (2023): 23345-23361."}, {"review_id": "e11XEG7kzQ", "reviewer": "Reviewer_Z1bD", "summary": "This paper tackles the inaccuracy of sampling-based profiles in Profile-Guided Optimization by framing profile inference as a learning problem on program graphs. It introduces a novel GNN architecture that merges an LSTM-based sequential encoder with GraphSAGE and graph-attention layers to capture both execution order and control-flow structure. The framework is integrated end-to-end within the LLVM PGO pipeline, training the GNN using sampled and instrumentation-based profiles with LLVM IR, and deploying it without intrusive instrumentation. This approach demonstrates significant empirical gains.", "questions": "A few questions and areas of improvement:\nQ: Can the approach handle JIT-compiled code (e.g., LLVM JIT) or dynamic languages?\nDiscussing how the model might be adapted or retrained for JIT scenario would strengthen the paper’s significance.\n\n\nQ: Which LLVM IR features (Table 8) are most importance?\nInclude an ablation where you remove groups of features to show their relative importance. If certain features are redundant, removing them could reduce model size/latency without hurting accuracy.", "limitations": "yes", "rating": 5, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 2, "strengths_and_weaknesses": "Strengths are:\n-well-structured presentation and clear problem motivation\n-addresses a practical bottleneck in industry-scale PGO and demonstrate end-to-end speedups integrated to LLVM, showing real-world impact\n\nWeaknesses are:\n-the main text could better summarize which static/dynamic features are most critical, which are in an appendix \n-scope is limited to statically compiled C/C++; applicability to JIT-compiled or highly dynamic languages is to be explored", "was_revised": true, "final_justification": "the rebuttal addressed concerns about the applicability and of the work by clarifying and acknowledging the use cases or potential adaptations for JIT-compiled and dynamic languages.", "rebuttal": "We appreciate the feedback from the reviewer.\n\n> Include an ablation where you remove groups of features to show their relative importance.\n\nWe conducted experiments on SEPC CPU 2017 where we removed groups of input features described in Appendix E to assess their impact on model performance.\n\nWe categorized the input features into five groups:\n\n1). Successor features, where each basic block’s input vector is augmented with its successors’ features,\n\n2). Control-flow features (e.g., number of predecessors/successors, loop headers),\n\n3). Memory operation counts (load/store/gep),\n\n4). Arithmetic and logic operations,\n\n5). Call and intrinsic counts.\n\n**Table 1.**\n\n| **Feature Group Removed** | **Overlap (%)** | **RMSE** | **$\\Delta$ Overlap vs Full Model** |\n| ------------------------- | --------------- | -------- | ---------------------------------- |\n| **None (Full Model)**     | **93.42**       | 0.034    | —                                  |\n| 1)                        | 90.06           | 0.044    | ↓ **3.36**                         |\n| 2)                        | 91.32           | 0.039    | ↓ 2.10                             |\n| 3)                        | 92.21           | 0.037    | ↓ 1.21                             |\n| 4)                        | 91.14           | 0.041    | ↓ 2.28                             |\n| 5)                        | 92.65           | 0.036    | ↓ 0.77                             |\n\n\nOur ablation results show that removing successor features leads to the largest drop in accuracy, indicating their critical role in modeling data/control dependencies. Control-flow and memory features also contribute meaningfully, while removing compute or call features has more moderate impact.\n\n\nThese results confirm that the feature design -- particularly the inclusion of successor semantics — is an important contributor to the model’s overall accuracy.\n\n\n\n> Which LLVM IR features (Table 8) are most important?\n\nThe feature ablation study (see Table 1 above) shows that that successor features, arithmatic-related features and control-flow related features are the most impactful, with the removal of successor features resulting in the largest performance drop. This highlights their importance in modeling control dependencies and flow-sensitive behavior.\n\n\n\n> Can the approach handle JIT-compiled code (e.g., LLVM JIT) or dynamic languages?\n\n\nIn principle, our approach is compatible with JIT-compiled code and dynamic languages, since it only requires access to the control-flow graph (CFG) and sampled or instrumented execution profiles. If the JIT compiler can emit an analyzable IR (e.g., LLVM IR) and profiling data, our method can be applied.\n\n\nThat said, the deployment context differs significantly from ahead-of-time (AOT) compilation. In dynamic language runtimes (e.g., JavaScript, Python, JVM-based languages), profiling and optimization are often tightly integrated into the runtime system itself. These systems typically use internal instrumentation or sampling during interpretation or early-stage JIT to collect hot path information, which is then used to guide tiered JIT compilation.\n\nExamples:\n\n- JVM HotSpot collects method and branch execution counts during interpretation, and uses this to optimize and inline hot methods at runtime.\n\n- V8 (JavaScript engine) performs on-stack replacement and dynamic deoptimization based on inline caches and runtime type feedback.\n\n- PyPy uses tracing JIT, where hot loops are detected and compiled based on interpreter-driven profiling.\n\n\nIn these systems, the runtime effectively performs its own version of profile-guided optimization (PGO) using dynamic profiling feedback. While our model could, in theory, be incorporated as a learned profile inference component within such systems, doing so would require:\n\n- Access to the JIT-compiled IR,\n\n- Alignment of runtime profile data with basic blocks or execution units,\n\n- Integration with the runtime’s internal optimization pipeline.\n\n\nWe view this as a promising future direction, and our method’s inductive generalization and reliance only on control-flow graphs and noisy profiles make it a strong candidate for such integration.We will clarify this point in the final version and highlight it as a potential application scenario in dynamic environments."}]

Author rebuttal:

Meta-review: The paper address the problem of predicting execution frequencies of code blocks from a sampling profiler. The method is a RNN-GNN architecture on the program's control-flow graph. 
The paper is well written and shows clear improvements compared to baselines for real-world compiler tasks. 
During the rebuttal, the authors produced more experiments to address concerns around ablations, neural baselines and other use cases such as JIT compilation.
While the amount of architectural novelty is limited, the empirical result show the solidity of the method for compiler optimization, and the reviewers agree mostly agree on the score.
Decision: Accept (poster)