A Problem-Oriented Perspective and Anchor Verification for Code Optimization
Authors: Tong Ye
Tengfei Ma
Xuhong Zhang
Hang Yu
Jianwei Yin
Wenhai Wang
Venue: ICLR 2026 Poster (2026)
Keywords: LLM4Code
Code Optimization
Primary area: applications to computer vision, audio, language, and other modalities

Abstract: Large Language Models (LLMs) have shown remarkable capabilities in solving various programming tasks, such as code generation. However, their potential for code optimization, particularly in performance enhancement, remains largely unexplored. This paper investigates the capabilities of LLMs in optimizing code for minimal execution time, addressing a critical gap in current research. The recently proposed code optimization methods constructs program optimization pairs based on iterative submissions from the same programmer for the same problem. However, this approach confines LLMs to local performance improvements, neglecting global algorithmic innovation. To overcome this limitation, we adopt a completely different perspective by reconstructing the optimization pairs into a problem-oriented approach. This allows for the integration of various ideas from multiple programmers tackling the same problem. Furthermore, we observe that code optimization presents greater challenges compared to code generation, often accompanied by "optimization tax". Recognizing the inherent trade-offs in correctness and efficiency, we introduce a novel anchor verification framework to mitigate this "optimization tax." Ultimately, the problem oriented perspective combined with anchor verification framework significantly enhances both the correct optimization ratio and speedup to new levels.

Published as a conference paper at ICLR 2026
A PROBLEM-ORIENTED PERSPECTIVE AND ANCHOR VERIFICATION FOR CODE OPTIMIZATION
Tong Ye', Tengfei Ma², Xuhong Zhang'; Hang Yu', Jianwei Yin', Wenhai Wang
'Zhejiang University, Stonn Brook University, 'AntGroup Jongye@zju.edu.cn edu.cn
ABSTRACT
Large Language Models (LLMs) have shown remarkable capabilities in solving various programming tasks, such as code generation. However, their potential for code optimization, particularly in performance enhancement, remains largely unexplored. This paper investigates the capabilities of LLMs in optimizing code for minimal execution time, addressing critical gap current research. The re- cently proposed code optimization methods construct program optimization pairs based on iterative submissions from the same programmer for the same problem. However, this approach confines LLMs to local performance improvements, ne- glecting global algorithmic innovation. To overcome this limitation, we adopt a completely different perspective by reconstructing the optimization pairs into problem-oriente approach. This allows for the integration of various ideas from multiple programmers tackling the same problem. Furthermore, code optimization presents greater challenges compared to code generation, of- ten accompanied by "optimization tax". Recognizing the inherent trade-offs in correctness and efficiency, we introduce a novel anchor verification framework mitigate this "optimization tax". Ultimately, the problem oriented perspective combined with the anchor verification framework significantly enhances both the correct optimization ratio and speedup to new levels.
observe that
INTRODUCTION
LLMs and Code LLMs, such as GPT-4 Series (OpenAl et al. 2024). CodeLLaMA (Roziere et al., DeepSeek-Coder Series (Guo al. 2024| Zhu et al. 2024) and Qwen-Coder Series (Yang) et al. 2024 Hui et al. 2024), have demonstrated remarkable capabilities in software engineer- ing tasks, garnering sigmificant attention from both academia and industry.
2023
tasks such as code
completion and code generation, Code LLMs achieve high correctness rates (Pass @ K) on widely used benchmarks like EvalPlus (Liu et al.) (023), LiveCodeBench (Jain et al., (025), and Big- CodeBench (Zhuo et al., 2025). However, despite these advancements, the code produced by these LLMs often falls short in real-world applications. may lack the necessary optimizations to meet specific performance and efficiency requirements (Shi et al. 2024 Niu et al. 2024). As result, the generated code often requires further refinement and optimization to align with practical constraints.
While lowelevel optimizing compilers and performance engineering tools have made significant ad- vancements (Alfred et al. 2007] Wang & O' Boyle, 2018). they primarily focus on hardware-centte optimizations. High-level performance considerations, such algorithm selection and API usage, still rely heavily on manual intervention by programmers. Automating high-level code optimization remains a major challenge and has yet be widely explored. Code optimization can be approached from various angles. In this work, we specifically focus on time performance, with an emphasis on minimizing program execution time, given its critical importance practical applications.
In the field of code performance optimization, the construction of optimization pairs is a critical chal- lenge. Unlike code generation, which only requires the collection of correct code, code performance optimization demands semantically equivalent code pairs with varying levels of efficiency. This
"Corresponding authors.

---

Published as a conference paper at ICLR 2026
Problem
Solutions
Snuke and Raccoon have heap cards. The i-th card from the has the integer written First, Snuke will take some number cards from the top the heap, then Raccoon will take all remaining cards. Let the sum integers on Snuke's cards and Raccoon's 's cards be and respectively. They would like minimize (x-yl. Find minimum possible value of (x-y].
Alice Solutions
A
A2
A
Ay
Bob Solutions
B,
B2
B3
Bp
Charii Sotutions
C2
C3
Cs
User Oriented
1
A
A3
A
A5
A6
Ax-1
Ax
Slow
Fast
Runtime
3706 ms
2503 ms
1778 ms 1020 ms
619 ms
389 ms
ms
ms
Problem Oriented
A
C
B
A
B3
C
Ay
CM
Slow
Fast
Runtime
3706 ms 2843 ms 2598 ms 2503 ms 745 ms
468 ms
56 ms
31 ms
Figure 1: For given problem, different users submit and iterate on their code solutions. The user oriented perspective constructs optimization pairs based on the individual users. In contrast, the problem oriented perspective analyzes all solutions for the problem to build trajectories.
dual requirement, ensuring both functional correctness and measurable performance improvements, makes dataset creation considerably more complex. Recent study (Shypula et al. (024) partly ad- dressed this challenge by collecting user iterative submissions from programming platforms, such as LeetCode, creating code optimization pairs (each consisting of less efficient code and its semanti- cally equivalent, more efficient counterpart). By utilizing these optimization pairs, researchers have initially demonstrated the potential of LLMs in code optimization tasks through domain fine-tuning.
However, the current approach of constructing code optimization pairs from iterative submissions by the same user has significant limitations. We refer to this as the User-Oriented approach. As shown in Figure [ user initially submits solution to a programming problem, but early ver- sions may fail to meet the system's time constraints due to excessive computational overhead. Through iterative refinements, the user eventually arrives cess captures the user's submission trajectory, which is used to construct optimization pairs such as A2), (A2, A3). (AN-1, AN). While this approach naturally reflects the direction of code optimization, it is inherently constrained by the thought patterns of single programmer. Con- sequently, improvements tend to be incremental, building upon existing logic and paradigms. A substantial number of intuitive examples (Figure 16 19p in Appendix TT also demonstrate this phe- nomenon. contrast, real-world code optimization thrives on collaborative diversity. Code review and refactoring processes deliberately involve multiple programmers to overcome cognitive iner- tia, with innovation arising from the synthesis diverse perspectives. Inspired by this insight, we hypothesize that combining different users' perspectives is beneficial for code optimization. There- fore, we propose shifting from the user-oriented perspective to a Problem-Oriente We restructure optimization pairs by incorporating solutions from multiple programmers addressing the same problem. As illustrated in the last part of Figure [ solutions from different users, ordered by runtime, form completely new optimization trajectory for the given problem. This problem- oriented perspective encourages diverse range of innovative ideas, fostering more holistic opti- mization process that better mirrors the complexity and creativity of program optimization. Multi- dimensional analysis and experimental results show that adapting Code L.MMs to problem-oriented optimization pairs greatly enhances optimization capabilities, leading to significant improvements in both optimization ratios (31.24% + 58.90%) and speedup x2.95 +5.22x)
more efficient solution. This pro-
perspective.
Simultaneously, code optimization is essentially a dual-objective process. aims to enhance code efficiency while ensuring the accuracy of the optimized code. However, in practice, we find that there is often a conflict between these two goals. That is, the code optimized by LLM can't be guaranteed to be completely correct. We refer to this phenomenon as the "optimization tax". To mitigate the practical challenge, we present an innovative anchor verification framework. The core idea is to leverage the "slow but correct" nature of pre-optimized code enhance the accuracy of
2

---

Published as a conference paper at ICLR 2026
the optimized code. Specifically, the anchor verification framework draws from widely used test case execution feedback mechanism like Chen et al. (2023); Wei et al. (2024); Chen et al. (2024a) in code generation tasks. These methods depend on synthesized test cases and bidirectional execution filtering to verify test cases and code. However, anchor verifiaction framework differs from these methods. Instead of directly synthesizing complete test cases, it first uses the LLM interpret the "slow code" and generate test case inputs. Then, it treats the "slow code" as a test case anchor to real execution to produce precise outputs for these test case inputs. By pairing each test case input with its corresponding execution output, we create complete and verified test cases. These verified test cases are then used for the iterative refinement of the "optimized code". Further experimental results show that anchor verification framework further unlocks performance bottlenecks and pushes code optimization to new levels, significantly improving both the optimization ratio (58.90% ~ 71 .66,, speedup (5.22 -6.08 x) and correctness (61 661.55% + 74.54%). In summary, the contributions are:
To the best of our knowledge, we are the first to introduce a problem-oriented perspective for code optimization. This perspective not only enhances the richness and diversity of optimiza- tion pairs but also significantly alleviates the data scarcity issue in code optimization.
We reveal the performance bottlenecks in code optimization, identify the "optimization tax" and introduce the anchor verification framework effectively mitigate the bottlenecks. The anchor verification framework fully utilizes the characteristies of the code optimization task: the code to be optimized, though inefficient,
least functional correct.
Multi-dimensional analysis and experiment results validate the effectiveness and robustness of both the mubllem-oriette, perspective and the anchor verification framework, significantly and simultaneously improving the optimization ratio, speedup, and correctness.
Overall Architecture: This paper begins by presenting problem-oriented perspective for con- structing optimization pairs in Section [1 In the associated experiments, we identify the "optimiza- tion tax" and highlight the relevant performance bottlenecks. Building on these findings, we propose a novel anchor verification framework in Section To further unleash LLMs' optimization potential.
2 PROBLEM-ORIENTER CODE OPTIMIZATION
In this section, we first introduce the key distinctions of the user-oriented perspective and the problem-oriented perspective in $ 22.1, Subsequently, we carry out in-depth multi-dimension analy- ses of both user-oriented and problem-oriented optimization pairs ($2.2). After that, we discuss the adaptation of Code LLMs to two perspective optimization pairs ($ 2.3) and furthermore conduct the optimization pairs percentage analysis and learning edit patterns analysis in $ 2.4
2.1 PROBLEM-ORIENTED OPTIMIZATION PAIRS
Orientr Perspective. In the current research, code optimization pairs are derived from PIE, introduced by Shypula et al. (2024), which focuses on optimizing program execution time by uti- lizing human programmers' submissions from wide range of competitive programming tasks on CodeNet (Puri et al.) 202T). A key aspect of developing PIE is recognizing the typical workflow of programmers: when faced with problem, they usually begin with initial solution and then iteratively refine it. As shown in Figure I for given problem P, users (Alice, Bob, etc.) have their submission trajectories, filter out incorrect submissions, and sort the rest in chronological order.
Alice valid submissions: [A1, A2, A3,
Avl
Bob valid submissions: BB, B2, By....,
Br)
Charlie valid submissions: [C1, C2, Ca...., CC.]
The user-oriented optimization pairs are constructed by extracting sequential pairs from each user's submission trajectory. For example, Alice's 's valid submissions generate optimization pairs such as (41,A2) (A2, As), and on, while Charlie's valid submissions result in optimization pairs like (C1, C2). (C2, Cs), and so forth. Ultimately, aggregating all these optimization pairs forms the complete user-oriented optimization dataset (PIE).
Problem-Oriented Perspective. While user-oriented optimization pairs indicate the direction of optimization, previously noted, they inherently confined by the cognitive patterns of single
3

---

Published as a conference paper at ICLR 2026
Problem User-oriented
Problem oriented
User oriented
#Count (Thousand)
100
50
-50
100
200
-100
Graph Edit Distances
-150
Figure 2: Program Structural Analysis of the Disparities between Problem-oriented Opti- mization Pairs and User-oriented Optimization Pairs using Graph Edit Distance (GED) metric.
150
Figure 3: Semantic Representation Analysis of Problem-oriented and User-oriented Pairs.
programmer. The detailed instances in Appendix T also illustrate this point, intuitively showing that the overall wroblem-solving approach and logical framework remain largely unaltered. Therefore, shift the perspective on optimization pairs and propose a problem-oriented construction method. Specifically, we regard all submissions for the same problem P from different users as a single group, thereby breaking down the barriers between different users. We sort all valid user submissions for the same P based on the marked runtime and map them onto the same optimization trajectories:
All users for problem P: [A1, C1 B1, A2, B3, C2. Casl
Subsequently, we construct optimization pairs along the wrriete-rieented trajectory, such as (Ai, (C1, Bi), (C1, B2), etc. Ultimately, this simple but not trivial process yields the novel problem-oriented optimization dataset. This new perspective not only reflects the direction of opti- mization but also integrates the diverse strategies and algorithms of different programmers.
Alleviating the Data Scarcity. The problem-oriented perspective also offers significant advantage in terms of scale. Let's assume there are P problems, each with U users, and each user has n. valid submissions. The user-oriented and problem-oriented perspectives exhibit substantial divergence in the scaling of optimization pairs:
1 # optimization pairs of user oriented
2 Ep 1u
ch
1 E E
optimization pairs of problem oriented
2
2
can be observed that when the number of users reaches 10, the number of problem-oriented op- timization pairs increases by order of magnitude compared to user-oriented optimization pairs. This is particularly advantageous for alleviating the data scarcity issue in code optimization domain.
2.2 MULTI-DIMENSION ANALYSIS
To rigorously and comprehensively compare code optimization pairs derived from two different per- spectives, we employ a multi-faceted analysis. Specifically, based on the problem-oriented approach proposed in 2. reconstruct the PIE train pairs, resulting in the PCO (Problem-orientee Code Optimization). To ensure comparability and fairness, we retained the same number of optimization pairs for each problem in PCO as the corresponding problem in PIE, selecting those with the top speedup rankings. This guarantees that both datasets contain a total of 78K optimization pairs, as shown in Table 5 We then perform comparative analyses across three different dimensions: Struc- tural Analysis, Semantic Representation Analysis, and Human & LLMs Sampling Analysis.
Structural Analysis. First, we delve into the structural differences between "slow" and "fast" code within the optimization pairs. To achieve this, we utilize Control Flow Graphs (CFGs), which ef- fectively capture the logical structure and execution pathways of program. In order to quantify the structural differences, minimum edit operation cost between the CFGs of "slow" and "fast" code. As shown in Figure 2 significant differences emerge from different perspectives: user-oriented optimization pairs exhibit
employ the Graph Edit Distance (GED) metric. This metric measures the
4

---

Published as a conference paper at ICLR 2026
relatively small average GED, indicating that the optimizations involve minor changes, such lo- calized optimizations. contrast, problem-orie oriented optimization pairs show a significantly higher average GED. This indicates that these optimizations often involve global changes, such algo- rithmic adjustments and major structural modifications, which contrast sharply with the incremental nature of the user-oriented perspective. Detailed instances we shown in Figure T6 19]
Semantic Representation Analysis. Beyond examining the structural differences within optimiza- tion pairs, we further investigate the semantic differences between these pairs. Specifically, we concatenate the "slow" and "fast" code snippets within each pair. These concatenated sequences are subsequently encoded using the CODET5P-1 110---MBEDDDIEN generates semantic embeddings. To facilitate visualization. these embeddings are projected using t-SNE (van der Maaten & Hinton 2008). As shown Figure g the embeddings for user-oriented pairs are tightly clustered, indicating that the code pairs represent similar coding semantics. In con- trast, the embeddings for the problem-orientee pairs are more dispersed, reflecting greater diversity.
model (Wang al.) 2023), which
Human & LLMs Sampling Analysis. Fur- thermore, we conduct a sampling analysis to investigate the optimization patterns. Specifi- cally, we randomly select 100 pairs from the PIE and PCO for human analysis, aiming to classify the types of optimizations applied. The optimizations categorized into three main types: global algorithmic optimizations, local optimizations, and other modifications (e.g., code cleanup), with details provided in the Ap- pendix C As shown Figure 4 human anal- ysis reveals distinct trends across the different perspectives: In PIE, true global algorithmic optimizations form smaller share. In contrast, the majority of program pairs in PCO fall into the global algorithmic optimization category, indicating stronger emphasis significant algorith- mic and structural improvements. The LLM analysis exhibits similar patterns, as shown in Figure
Problem-orientee
User-oriented
80
78.0
Percent (%)
6:0
44.0
20
19.0
EZZ
Global
Local
Other
Figure 4: Human Analysis of the Optimization Types of Different Perspective.
2.3 ADAPTING LLMS TO OPTIMIZATION PAIRS
Subsequently, we conduct supervised fine-tuning adapt LLMs problem-oriented (PCO) and user-oriented (PIE) optimization pairs, to evaluate their performance in code optimization domain.
Metrics. evaluate the optimization performance, we adopt the metrics from Shypula al. (202)):
Percent Optimized [%OPT]: The fraction of programs in the test set improved by a certain method. A program must be least 10% faster and correct contribute.
Speedup (SPEEDUP]: The absolute improvement running time.
and n are the "old" and "new" rumning times, then SPEEDUP(O, N) (2). A program must be correct contribute.
Percent Correct [CORRECT]: The proportion of programs in the test set that are functionally equivalent the original program (included as a secondary outcome).
We count a program as functionally correct only if it passes every test case. Additionally, we re- port SPEEDUP as the average speedup across all test set samples. For generated programs that are either incorrect or slower than the original, we use speedup of 1.0x, hence, in the worst case, the original program has a speedup of 1.0 (further explanation is shown in Appendix (G). We benchmark performance using the gem5 CPU simulator environment (Binkert et al.] (20T)) and compile all C++ programs with GCC version 9.4.0 and C++17 as well as the -03 optimization flag. Therefore, any reported improvements would be those on top of the optimizing compiler.
Code LLMs Selection. We select GPT-4 (0613), GPT-40 (Achiam et al. 2023 OpenAl et al, 2024]. CODELLAMA (Roziere et al. 2023) DEEPSEEK series (Guo al. [024 DeepSeek- 2025)
and 2VEN2,5-CoDDE series (Hui et al. 2024) for code optimization. Detailed training configura-
tion details, fine-tuning overhead, and GPU hours are provided in Appendix
Decoding Strategy. Code generation benefits from sampling multiple candidates and selecting the best one; in case, the "best" refers the fastest program that passes all test cases. We use
5

---

Published as a conference paper at ICLR 2026
Table 1: Prompt and Eine-Tuning Results for LLMs on PIE and PCO with BEST and BEST @8.
Prompt
LLMs
BEST @
BEST@S
/ Dataset
& Code LLMs
%OPT
SPEEDUP
CORRECT
%OP
SPEEDUP
CORRECT
Instruct Instruct
DEEPSEEKCODER 33B
5.28%
1.12x
30.17%
14.83%
1.23x
48.00%
GPT-4
12.37%
1.19x
75.28%
22.81
1.38x
91.74%
CoT
DREPSEEK CODER 33B
13.91
1,24
37.45%
20.81
1.55x
61.89%
CoT
GPT-4
23.43%
1.37
48.65
47.92%
1.74x
80.53%
CoT
GPT-40
28.39%
2,42x
56.48%
50.28%
2.77x
83.34%
CoT
DEEPSEEK
31.92%
2.78x
58.93%
53.86%
3.02x
87.32%
PIE
CODELLAMA 13B
12.98%
1.73x
47.45%
41.65%
2.85
72.27%
PIE
DEEPSEEKCODER
23.56%
2.29X
41.27%
47.23%
3.34x
69.23%
PIE
DEEPSEEKCODER 33B
27.57%
2.77x
50.49%
56.76%
3.83x
81.14%
PIE
QWEN2,5-CODER 7B
26.96%
2.80
41.21%
56. 17%
3.85x
78.54%
PIE
QWEN2,5-CODER 32B
31.24%
2.95x
46.52%
60.89%
4.11x
87.95%
PCO
CODELLAMA 13B
31.83%
3,23x
44.26%
55.87%
4.89
69.61%
PCO
CREPSEEKCODER 7B
44.38%
4.31
45.71% %
71.53%
6.24x
73.09%
PCO
DEEPSEEKCODER 33B
49.83
4.57x
50.64%
74.87%
6.67x
78.29%
PCO
OWEN2.5-CODER
54.83%
4.73x
56.26%
75.28%
6.89x
77.43%
PCO
SWEN2.5-CODER 32B
58.90%
5.22x
61.55%
80.77%
7.22x
83.03%
BEST @ denote this strategy, where k represents the number of samples and the temperature is set to 0.7. we use vLLM (Kwon et al. 2023) for inference and detailed prompts are in Figure TO]
2.4 ADAPTING RESULTS.
Instruction Prompting. First, we use instruction prompts to guide the LLMs in optimizing code. Additionally, inspired by Chain-of-Thouge (Wei et al. (2022), we ask the LLMs reason about how to optimize the program before generating the optimized version. Details of Instruction/Col1 prompts are in Appendix M Table that using instruct prompt and CoT did not significantly improve % OPT and SPEEDUP. The best performance by DEEPSEEK-V3 achieved 53.86% OPT and 3.02x under BEST@ 8. Additionally, we observe that using CoT for optimization speeds up the program but can lead decline in CORRECT due to the complexities it introduces.
Fine- Tine-Tuning Results. As shown in Table I whether for different LLM series or varying parameter scales, significant performance differences observed when finetuned user-oriented (PIE) and problem-oriented (PCO) optimization pairs. QWEN2.5-CODEL 32B on PCO at BEST 1, demon- strates substantial improvements: %OP (31.24% + 58.90%) SPEEDUP CORRECT (46.52% + 61.55%) compared to finetuned on PIE. At BEST @8, %OP and SPEEDUP reached 80.77% and 7.22x, respectively. This indicates significant advantage in adapting to problem-oriented optimization pairs compared to user-oriented optimization pairs.
+9.2xx) and
We observe that, unlike BEST @ CORRECT slightly declines for most LLMs adapted on PCO under BEST @& 8 compared to PIE. This is because LLMs adapting on PCO results in more significant modifications the code in pursuit maximum efficiency, which slightly disrupts the balance of CORRECT. However, the gains in %OPT and SPEEDUP are substantial under BEST @ 8.
Finding 1:
Finding 2: For LLMs adapted on PCO, both %PP and CORRECT are much closer compared to PIE. This suggests that when the optimized code is correct, it is highly likely to be optimized. The closer %PT and CORRECT are, the higher the proportion insight also indicates that, for LLMs adapted PCO, to further increase the optimization ratio and speedup, the performance bottleneck lies in ensuring correctness.
"correct will be optimized". This
PCO Percentage Analysis. We further explore how fewer PCO optimization pairs impact %OPT, SPEEDUP, and CORRECT. To investigate this, we randomly selected certain percentage of op- timization pairs from PCO, reducing the number of pairs from 90% down 10%, and fine-tuned QWEN2.5-CODER 32B in the same way. As shown Figure [S] even with just 30% of the PCO optimization pairs, LLMSs adapted on PCO achieve both 6PT and SPEEDUP that surpass those

---

Published as a conference paper at ICLR 2026
Percent
SPEEDUP
Correct Porcent
5.0
50
5.5
5.0
4.5
4.0
3.5
30
3.0
NOPTINO
2.5
Spoodas PCD
Censut PCD
20
NORT INO Pavsrtt
2.0
-0
Spoodan FCD Nover:
Spooden PI
Genedt PCD Paweet
100
80
70
60
50 Parcent
40
30
20
10
100
50
80
60 PCD
50
40
30
20
10
100
90
80
70
20
10
PCO
Percent
Percent
Figure 5: Performance impact of using varying percentages of PCO optimization pairs (from 100% + 10%) on %OPT, SPEEDUP, and CORRECT. The blue line represents the original PCO datasets, while the yellow line represents the original PIE datasets.
of the full PIE. Furthermore, with roughly half of the PCO pairs, CORRECT matches the full PIE. These results highlight the impressive data efficiency of the problem-oriented perspective, where fewer optimization pairs can still deliver competitive or even superior performance compared to full user-oriented optimization pairs.
Disentangling Perspective and Selection Effects. To rigorously evaluate the respective contribu- tions of perspective versus optimization pairs selection strategy, we conducted a controlled ablation study by fine-tuning OWEN2.5-CoDES 7B on three datasets under identical settings: PIE (original user-oriented), PCO-Random (randomly sampled from problem-oriented pairs while matching PIE's scale), and PCO-Top-Speedun (original PCO). Experimental details are provided in Appendix [H] Results show PCO-Random substantially outperforms PIE across all metrics, confirming that the problem-oriented perspective itself drives performance gains. The additional improvement with SCo-eup- demonstrates that top-speedup sampling provides the best refinement. These findings establish that while selective sampling enhances performance, the core advantage stems from aggregating diverse solutions across users through the toriete perspective.
Learning Edit Patterns. To further investigate whether PCO can distill effective algorithmic- improvement patterns from pairs with large structural disparities, conducted an empirical study (Details in Appendix O). The study demonstrates that the edit-pattern (i.e., the algorithmic optimiza- tion pattern) learned by PCO transferable and robust, rather than a mere conditional generation.
Cost-Benefit Analysis of BEST @k Strategy. The BEST @ strategy provides explicit control over the cerformance-compputtion trade-off in code optimization. Experimental results (as shown in Ap- pendix K demonstrate that while token costs scale linearly with the number of samples k. perfor- mance improvements follow a pattern of diminishing returns. This characteristic enables flexible de- ployment strategies: BEST @ serves as the most efficient option for production environments with limited computational budgets, while progressively higher values of & deliver enhanced optimiza- tion for assuuace-buuddat scenarios. The strategy thus allows practitioners to balance optimization quality against inference costs according to their specific requirements.
Validation on Physical Hardware. We complement the gem5-based evaluation with performance measurements on physical hardware to assess real-worke optimization effectiveness. Detailed results and analysis are provided in Appendix P
ANCHOR VERIFICATION FRAMEWORK FOR PRACTICABILITY
we uncover the key challenge inherent in LLM code optimization. Whether through instruct prompting or finetuning, there is always a risk that optimized code may not be 100% correct. We refer to this phenomenon as the "optimization tax". To tackle the challenge of "optimization tax", we propose a novel anchor verification framework that leverages the original "slow code" as a gold-standard verification anchor: Unlike refinement in genenral code generation, which often relies on potentially error-prone synthetic test cases for refinement, the code optimization scenario has the unique advantage: the "slow code". despite its inefficiency, is functionally correct. This inherent characteristic positions as an ideal test case verification anchor. Building on this insight, we design the anchor verification framework (Figure 6). which consists of three main stages:
In Section 2
7

---

Published as a conference paper at ICLR 2026
Slow Code
Anchor Verification Framework
Optimized Code
Stagel; Explain
Pxplainn This code implements
Stage 3: Executing verified test cases and sterative refinemsuur
and generule
simple sequence generation duplicate desection algorithen...
uniine perortes
input.
Test case input.
BB
Input Input 3
Jnput
Inpur N: -5
"pothuialo C
Verifled Test Cases
the dourtt Movetertte
Stuge Filter invalid input and execuse on slow code.
Conculeraate verified test case input oulpul.
Aayur Inpur
Quiput
Ouiput 2:
retumn
Expur 7
Oniput 3:
Jupur N: Ouiput N:
Figure 6: Anchor Verification Framework. includes three stages: (1) generating test inputs based on the slow code's functionality, (2) constructing verified test case set by executing inputs through the slow code, and (3) iteratively refining the optimized code with execution feedback.
Table Results of Anchor Verification Framework and compared methods with OWEN2,5-CODER, GPT-4o, and DEEPSEEK- V3 on BEST @ 1. The baseline is the output of OWEN2.5-CODER 32B on PCO in T The improvement (denoted as A) is measured against the baseline (w/o refinement).
BEST@!
LLMs
Methods
%PPPT
A 1
SPEEDUP
A
CORRECT
A
Baseline (w/o refinement)
58.90%
5.22x
61.55%
Self Debugging
58.42%
-0.48
5.13x
-0.09
61.14%
-0.41
QWEN2.5- CODER 32B
Direct Test Generation
62.98%
+4.08
5.46x
+0.24
65.95%
+4.40
INSTRUCT
Anchor Verification (Ours)
64.75%
+5.85
5.67x
+0.45
67.28%
+5.73
Self Debugging
61.96%
+3.06
5.59x
+0.37
63.60%
+2.05
Direct Test Generation
65.43%
+6.53
5.71
+0.49
68.61%
+7.06
GPT-4o
Anchor Verification (Ours)
68.40%
+9.50
5.90x
+0.68
71.98%
+10.43
Self Dehugging
64.11%
+5.21
5.63x
+0.41
65.64%
+4.09
Direct Test Generation
66.26%
+7.36
S.81
+0.59
69.53%
+7.98
DEEPSEEK- V3
Anchor Verification (Ours)
71.06%
+12.16
6.08
+0.86
74.54
+12.99
Stage 1: Test Inputs Generation. In the first stage, the LLM is prompted to explain the functional- ity of slow code" and guided generate a set of test inputs. These test inputs are designed to cover the boundary cases of the implemented functionality of "slow code". Unlike general LLM-based test case generation, this stage focuses solely on generating valid and meaningful test case inputs.
Stage 2: Verified Testcase Construction. Based on the obtained test case inputs in the first stage, we feed these inputs to the "slow code" for compilation and real exccution. Although the "slow code" is inefficient, it can produce the correct execution results. We filter out test case inputs that don't 't match the input format and gather the corresponding output results. After that, we combine the test case inputs and corresponding outputs to form fully verified test case sets.
Stage 3: Iterative Refinement. Leveraging the verified test case sets, we compile and execute the optimized code to check its correctness. If any error occurs, similar to the feedback refinement mechanism in general code generation, we provide the execution error information to the LLM backbone, enabling it to iteratively refine the optimized code.
3.1 EXPERIMENT RESULTS
Compared Methods. To rigorously validate the effectiveness of anchor verification framework, we benchmark against two compared methods. Details explanations of baselines are in Appendix Q
Self-Debugging: following Chen et al. (2024b), the self-debugging method prompts the LLM to provide line-by-line explanations of the generated code as a feedback signal for refinement.
Direct Test Generation: the LLM directly generates complete test cases (including inputs and outputs) and uses these synthetic test cases execute and iteratively refine the optimized code.
8

---

Published as a conference paper at ICLR 2026
Experiments Setup. In the experiments, for all three methods, the maximum iteration count is set to 1. Detailed implementations and all corresponding prompts are also provided in Appendix [
Main Results. We use the output of "QWEE2.55- last row in Table D.. We experimented with three different LLM backbones: INSTRUCT, GPT-40, and DEEPSEEK- V3, with the results shown in Table 2 All methods showed performance gains, except for a slight decline in the self-debugging with QWEN2.5- STRUCT. The decline can be attributed the high demands on the LLM's ability for self-explanation and correction, and QWEN2.5-CODER 32B INSTRUCT's overall performance still lags behind the other two LLMs. Anchor verification framework demonstrated the best improvements across all three LLM backbones, particularly with DEEPSEEK- V3. Compared to the baseline, CORRECT im- proved by 12.99%. %OPT improved by 12.16%, and SPEEDUP increased to 6.08x. This result confirms that CORRECT is the performance bottleneck, and that improving CORRECT can simul- taneously enhance both %OPT and SPEEDUP. Additionally, we also performed experiments using the output of (0WEN2.5-CODER 32B finetuned on PIE" the baseline, as shown in Table [4 The conclusions are similar, and anchor verification continues to deliver the highest performance gains.
32B finetuned on PCO" the bascline (the
--CDEER 32B
32B IN-
Root Cause of Performance Differences. To further investigate whether the difference in test case output is the root cause of the performance difference, we conducted additional comparisons. In Comparion Group, the testcase outputs are generated by the LLM based on "slow code" and the testcase input, instead of real executing the "slow code". Everything else remained unchanged.
Table shows that the Comparison Group falls short of the Anchor Ver- ification. This indicates that the par- tially inaccurate outputs of test cases (approx.16%) do indeed negatively impact the subsequent refinement by the LLM and underscoring the ne- cessity of executing test case inputs obtain their outputs within Anchor Verification. Furthermore, Compari- son Group performed slightly better than Direct Test Generation, suggesting that the two-step approach (LLM generating testcase inputs and outputs separately) places less burden on the LLM compared to directly generating the entire testcase. Consequently, the test case quality is superior.
Table Root Cause of Performance Differences.
BEST @ 1
DEEP V3
%OPT
SPEEDUP
CORRECT
Basc
58.90%
5.22x
61.55%
Direct Test Generation
66.26%
5.81 x
69.53%
Comparison Group
68.30%
5.91
70.86%
Auchor Verification 71.06%
6.08x
74.54%
Increase the Number of Iterations. In the experiment setup, the iteration count for all three meth- ods was initially set one iteration. To investigate the impact of multiple iterations on performance, we further verified the scenarios with
Table 4: Increase the Number of Iterations.
three and five iterations. As shown in
T the first iterations of both Di-
BEST @
rect Test Generation and Anchor Ver- ification yield most significant per- formance gains. Moreover, for Direct Test Generation, the performance im- provement from five iterations com- pared with three iterations is barely evident. In contrast, Anchor Verifica- tion still shows marked improvement. This further highlights the value of verified correct test cases for execu- tion feedback refinement and allevi- ating the "optimization tax."
DEEPSEEK-VS
OPT
SPEEDUP
CORRECT
Base
58.90%
5.22x
61.55%
Number of Iteration =
Direct Test Generation
66.26%
5.81x
69.53%
Anchor Verification
71.06%
6.08x x
74.54%
Number of Iteration 3
Direct Test Generation
68.30%
5.89x
70.76%
Anchor Verification
74.85%
6.19x
77.81%
Number of Iteration
=
Direct Test Generation
68.91%
5.92x
71.57%
Anchor Verification 78.43%
6.37x
79.24%
Primary Reasons for Remaining Failures. The empirical findings reveal an inherent trade-off between efficiency and correctness in program optimization: any attempt to accelerate a function- ally correct but inefficient program risks introducing semantic deviations. Although the Anchor Verification Framework substantially reduces the error rate, it cannot eliminate persistent errors en- tirely. Consequently, achieving the ideal goal of cirroccorrectess-looss optimization" " remains an open challenge that deserves continued investigation. A systematic analysis of failures (shown in

---

Published as a conference paper at ICLR 2026
Appendix Th reveals that roughly half fall into the "Compiled, but semantically wrong" category, indicating that current LLMs still have blind spots in comprehending high-level program intent.
Practical Cost. To investigate the overhead of the Anchor Verification Framework, we measured the corresponding time cost for each stage (as shown in Appendix D.) The results reveal that its overhead is nearly identical that of "Direct Test Generation". This similarity arises because the two approaches share all major stages (e.g.. code comprehension); the only extra step is the local sandbox execution that runs in milliseconds and incurs minimal cost compared to other stages.
Case Study. Additionally, we present case studies to intuitively show specific examples and inter- mediate results of the Anchor Verification Framework, as illustrated in Figure 20 21 and 22
Related Work, The detailed review of related work is provided in Appendix B
GENERALIZABILITY
Generalizability Beyond C/C++. To assess the cross-language applicability of the problem- oriented perspective and Anchor Verification Framework. replicated the core experiments on Python. Following the same dataset construction procedure as for C++, Python versions of PIE and PCO datasets were built from CodeNet. Since Python is not compatible with the gem5 simulator, we utilized cP roffir fi e for fine-grained runtime performance analysis. Experimental results consis- tently demonstrate the approach's 's effectiveness in Python. The problem-oriented perspective yields substantial improvements, with PCO-adapted models showing significant gains in optimization rate and speedup compared to user-oriented counterparts. Higher correctness rates in Python align with established findings that LLMs generally exhibit stronger comprehension of Python semantics, con- firming that the problem-oriented perspective's 's advantages are not language- the Anchor Verification Framework was further validated in Python using DEEPSERK- V3 to refine PCO-finetuned QWEN2.5-CODER 32B outputs. The framework consistently achieved best per- formance while significantly enhancing output correctness, reinforcing that leveraging functionally correct but inefficient code as a trusted anchor represents a general and effective strategy for opti- mization across programming languages. Detailed experimental results are provided in Appendix []
Furthermore,
Discussion of Generalizability to Complex Real-World Scenarios. While the problem-oriented perspective and the Anchor Verification Framework have demonstrated strong performance. their core design philosophy also exhibits potential for generalization to more complex real-world soft- ware optimization scenarios. In practical development environments, the problem-oriented perspec- tive naturally extends to situations where multiple developers collaboratively optimize the same code component over extended periods. For example, in long-maintained open-source projects or large- scale enterprise codebases, sequential optimization attempts targeting specific performance bottle- necks-often documented in version control histories-can be viewed as problem-oriented opti- mization trajectories that the proposed approach can effectively leverage. In particular, performance- critical components typically undergo multiple optimization iterations by different developers, where each performance-improvin commit represents a unique "solution" to the persistent op- timization "problem" of that component. The sequence of such commits forms the exact type of problem-oriented optimization trajectory that this methodology is designed to capture and uti- lize. Similarly, the Anchor Verification Framework shows strong generalization potential through its component-level anchoring mechanism. In microservice architectures modular systems, thor- oughly tested yet suboptimal service modules can serve as reliable verification anchors. Extending this methodology to address leste challenges and apply it to optimization problems in large- scale codebases represents a natural and important direction for future research.
CONCLUSION
In this paper, we introduce a problem-oriented perspective and an anchor verification framework for code optimization. The problem-oriented perspective not only enhances the diversity of optimization pairs but also significantly mitigates the data scarcity issue in the domain of code optimization. The anchor verification framework effectively alleviates the "optimization tax" while simultaneously elevating the optimization ratio, speedup, and correctness to new levels. We hope these insights will offer a practical and effective path toward advancing program efficiency.
10

---

Published as a conference paper at ICLR 2026
ACKNOWLEDGMENTS
This work is supported by the Fundamental Research Funds for the Central Universities (Zhejiang University NGICS Platform).
REFERENCES
Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Ale- man, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 2023. URL htttps://arxiiv.orr/aas/////// 08774
V Aho Alfred, S Lam Monica, and D Ullman Jeffrey. Compilers Principles, Techniques & Tools. pearson Education, 2007. URL htap:s://ee.wwkeeee aitkipea....iiiieii.a.... and Tools
Principles,__echmee
David F. Bacon, Susan L. Graham, and Oliver J. Sharp. Compiler transformations for high- performance computing. ACM Comput. Surv, 26(4):345 420, dec 1994. ISSN 0360-0300. doi: 10.1 10.1145/197405.19772
SRLLtttp://aci..rg// 1145/9497770051 197406
Nathan Binkert, Bradford Beckmann, Gabriel Black, Steven K. Reinhardt, Ali Saidi, Arkaprava Basu, Joel Hestness, Derek R. Hower, Tushar Krishna, Somayeh Sardashti, Rathijit Sen, Korey Sewell, Muhammad Shoaib, Nilay Vaish, Mark D. Hill, and David A. Wood. The gem5 Simulator SIGARCH Comput. Archit. News, 2011.
Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. Codet: Code generation with generated tests. In The Eleventh International Confer- Learning Representations, 2023. https:/ http///pppeeoeo.eeeeooeeeeeeeeep net http://wwwwe/foouumemmm forum?id=
Mouxiang Chen, Zhongxin Liu, He Tao, Yusu Hong, David Lo, Xin Xia, and Jianling Sun. B4: Towards optimal assessment of plausible code solutions with plausible tests. In Proceedings of the 39th IEFF/ACM International Conference on Automated Softwae Engineering, ASE 244 pp. URL http://t>> doi.
1705.1755. ACM, October 2024a. doi: 10. 10.1145/369162003695558
oxg/10..114/3596600 3695536
Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. Teaching large language models to self-debug. In The Twelfth International Conference on Learning Representations, 2024b. URL
https:://ppereviiee net/ forum Sttpeerreeeeeeeeeeeooooooiiooaae Lttt//fooommmGLKKPLLLgLgG
reasonin DeepSeek-AI. Deepseek-rl: Incentivizing reasoning capability in lims via reinforcement learning,
2025. [RRl:tttss///rrxi..orr//////
Spandan Garg, Roshanak Zilouchian Moghaddam, Colin B. Clement, Neel Sundaresan, and Chen
Wu. Deepperf: A deep learning approach for improving software performance, 2022. URL
https::/arxiv.. wttp:iii.rrg/aaa. http://aawwii..oooa///////////// 12619
Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong. Wentao Zhang, Guanting Chen, Xiao Bi, Y Wu, YK Li, et al. Deepseck-coder: When the large language model meets programming- the rise of code intelligence. arXiv preprint arXiv:240I. 14/96, 2024. URL httptttts:///xii org/ abs/ 2401. 14196
Edward J Hu, yelong shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. LoRA: Low-rank adaptation of large language models. In International Con- ference on Learning Representations, 2022. URL https: http////peeeeeeeeeeeee/e /eeee.es/eeeeeeeeeeeiiee.. sepeenreveew.net/fooomm net/forum?
id=nZeVKeePYff
Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Kai Dang, et al. Qwen2. 5-coder technical report. arXiv preprint arXiv:2409. 12186, 2024.
11

---

Published as a conference paper at ICLR 2026
Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Ar- mando Solar-Lezama, Koushik Sen, and Ion Stoica. Livecodebench: Holistic and contamina- tion free evaluation of large language models for code. In The Thirteenth International Confer- ence on Learning Representations, 2025. URL htttps://openrewe ew. wtt.:ww...e..teeeee////e forum? i=
chfJJYC311
Pascal Kerschke, Holger H. Hoos, Frank Neumann, and Heike Trautmann. Automated algorithm selection: Survey and perspectives. Evolutonaay Computation, 27(1):3-45, 2019. doi: 10.1 162/ evco a 00242.
Thomas Kistler and Michael Franz. Continuous program optimization: A case study. ACM Trans. Program. Lang. Syst. 25(4):500- 548, jul 2003. ISSN 0164-0925. doi: 10.1145777559.7785622
URL htR.:tttsss//oo..2//111.....
778562,
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng. Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023.
Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et Competition-level code generation with alphacode. Science, 378266)) 2022. URL htt.httss//// www. sc ence. org/
10. 1te.1o...1/cciiii /ttp/////iicceeeemccc abq1158
Jhe-Yo Yu Liou, Xiaodong Wang, Stephanie Forrest, and Carole-Jean Wu. Gevo: Gpu code optimiza- tion using evolutionary computation. ACM Trans. Archit. Code Optim., 17(4), nov 2020. ISSN 1544-3566. doi: 10.1145/3418055 80055. URL https: /tt.//ii..ggo/////// 114./111555500 11111144////555 3418055
Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. Is your code generated by chatGPT really correct? rigorous evaluation of large language models for code generation. In Thirty-seventh Conference on Neural Information Processing Systems, 2023. URL https::/
wwwpreewwwwwwet/foooo Pid-lmmiiiiio 1wwmmmddd11111111mm eevx610Cu7
Ilya Loshchilov and Frank Hutter. Decoupled weight decay regularization. In International Confer- ence on Learning Representations, 2019. URL ptttps://openrevieee net.leewwweeeeeeeeeeeeeeeeeeeeee formm?id
Bkg6RiCqY7
Seungjun Moon, Hyungjoo Chae, Yongho Song, Taeyoon Kwon, Dongjin Kang, Kai Tzu iunn Ong, Seung won Hwang, and Jinyoung Yeo. Coffee: Boost your code Ilms by fixing bugs with feed- back, 2024. URL http::tttt//xiiiiste
abs/
Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. Codegen: An open large language model for code with multi-turn program synthesis. In The Eleventh International Conference on Learning Representations, 2023. URL
https: http://ppeneeeeeeeccec net Eorum:idd-aaacJKaa
Changan Niu, Ting Zhang, Chuanyi Li, Bin Luo, and Vincent Ng. On evaluating the efficiency of source code generated by llms, 2024. URL https:/::::/// /ttp:s////axvvv.o/ http//aaxx....raaa.a./. wwtp/////g///aaaae/.eo 2404. 06041
Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar- Lezama. Is self-repair silver bullet for code generation? In The Twelfth International Confer- ence on Learning Representations, 2024. URL https::t////c..... http:///ppneeeeiieee wtt.:/wwwww.tte.nu/ee..... y0GJXRungR
OpenAI, :, Aaron Hurst, Adam Lerer, Adam P. Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, Aleksander Mądry, Alex Baker- Whitcomb, Alex Beutel, Alex Borzunov, Alex Camey, Alex Chow, Alex Kirillov, Alex Nichol, Alex Paino, Alex Renzin, Alex Tachard Passos, Alexander Kirillov, and et al. Gpt-4o system card, 2024. URL http::////.aaa..cc/aaaa//2//0000 21276
Ruchir Puri, David S Kung. Geert Janssen, Wei Zhang, Giacomo Domeniconi, Vladimir Zolotov, Julian Dolby, Jie Chen, Mihir Choudhury, Lindsey Decker, et al. Codenet: A large-scale ai for code dataset for learning a diversity of coding tasks. arXiv preprint arXiv:2105. 2021. URL (tRl:ttts: /ttp///wvvvv/////////////////av wtwgg/abs//000 12655
12

---

Published as a conference paper at ICLR 2026
Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi. Jingyu Liu, Tal Remez, Jérémy Rapin, et al. Code Ilama: Open foundation models for code. arXiv preprint arXiv:2308
2023. URLhttps: /ttpss//aaaiiii wwtp///////.a.....o// 12950
ab////b//2/
Jieke Shi, Zhou Yang, and David Lo. Efficient and green large language models for software en- gineering: Literature review, vision, and the road ahead, 2024. URL
abs/2404, 04566
Alexander G Shypula, Aman Madaan, Yimeng Zeng, Uri Alon, Jacob R. Gardner, Yiming Yang, Milad Hashemi, Graham Neubig. Parthasarathy Ranganathan, Osbert Bastani, and Amir Yaz- danbakhsh. Learning performance-improving code edits. In The Twelfth International Confer- ence on Learning Represenlations, 2024. URL htt.hhtp//// pettps://openreyee ew. net/ / forum? ?id= ixTrIWHXyY
Zifan Song, Yudong Wang, Wenwei Zhang. Kuikun Liu, Chengqi Lyu, Demin Song, Qipeng Guo, Hang Yan, Dahua Lin, Kai Chen, and Cairong Zhao. Alchemistcoder: Harmonizing and eliciting code capability by hindsight tuning multi-source data. In The Thirty-eighth Anmual Confer- ence on Neural Information Processing Systems, 2024. URL https: http///ppprreeeeeeeeeeeeeeeeeeer .ne// .ntt/ Eorum? SAQXbnvv4E
Laurens van der Maaten and Geoffrey Hinton.
Visualizing data using t-sne. Journal of Ma- chine Learning Research, 9886):559-2605,, 2008. URL http: / jmlr org/ /99
vande raa.teenmaattn00800 html
Yaoxiang Wang. Haoling Li, Xin Zhang, Jie Wu, Xiao Liu, Wenxiang Hu, Zhongxin Guo, Yangyu Huang. Ying Xin, Yujiu Yang, Jinsong Su, Qi Chen, and Scarlett Li. Epicoder: Encompassing diversity and complexity in code generation, 2025. 04694
Yue Wang. Hung Le, Akhilesh Gotmare, Nghi Bui, Junnan Li, and Steven Hoi. CodeT5+:
Open code large language models for code understanding and generation. In Houda Bouamor, Juan Pino, and Kalika Bali (eds.), Proceedings of the 2023 Conference on Empirical Methods in Natural Lan- guage Processing, pp. 1088, Singapore, December 2023. Association for Computational org/
Linguistics. doi: 10. 1211188551122223 http://22...mmmmmmm.a..... URL 1023.emm.ll main..... 68/]
Zheng Wang and Michael O' Boyle. Machine learning in compiler optimization. Proceedings of the IEEE, 106(11):1899-1901, 2018. doi: 10.1 10010////....221188881171 URL https:// leeexplore /etp...cr.bbsttttt/cccteeeeeeeee
Jason Wei, Xuezhi Wang. Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V
Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning in large language models. In S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh (eds.), Advances in Neural Information Processing Systems, volume 35, pp. 24824 24837. Curran Associates, Inc., 2022. URL
File/
Yuxiang Wei, Zhe Wang. Jiawei Liu, Yifeng Ding, and Lingming Zhang. Magicoder: Source code is all you need, arXiv preprint arXiv:2312.02122 2023. URL
2312.02120
Yuxiang Wei, Federico Cassano, Jiawei Liu, Yifeng Ding, Naman Jain, Zachary Mueller, Harm de Vries, Leandro von Werra, Arjun Guha, and Lingming Zhang. Selfcodealign: Self-alignment for code generation. arXiv preprint arXiv:2410.2411 2024.
An Yang, Baosong Yang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Zhou, Chengpeng Li, Chengyuan Li. Dayiheng Liu, Fei Huang, Guanting Dong, Haoran Wei, Huan Lin, Jialong Tang, Jialin Wang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Ma, Jin Xu, Jingren Zhou, Jinze Bai, Jinzheng He, Junyang Lin, Kai Dang, Keming Lu, Keqin Chen, Kexin Yang, Mei Li, Mingfeng Xue, Na Ni, Pei Zhang, Peng Wang, Ru Peng, Rui Men, Ruize Gao, Runji Lin, Shijie Wang, Shuai Bai, Sinan Tan, Tianhang Zhu, Tianhao Li, Tianyu Liu, Wenbin Ge, Xiaodong Deng, Xiaohuan Zhou, Xingzhang Ren, Xinyu Zhang, Xipin Wei, Xuancheng Ren, Yang Fan, Yang Yao, Yichang
13

---

Published as a conference paper at ICLR 2026
Zhang, Yu Wan, Yunfei Chu, Yuqiong Liu, Zeyu Cui, Zhenru Zhang, and Zhihao Fan. Qwen2 technical report. arXiv preprint 7Xiv:2407.106711 2024.
Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye, Zheyan Luo, Zhangchi Feng, and Yongqiang Ma. Llamafactory: Unified efficient fine-tuning of 100+ language models. In Pro- ceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), Bangkok, Thailand, 2024. Association for Computational Linguis- 13372
tics. URL
Li Zhong, Zilong Wang, and Jingbo Shang. Ldb: A large language model debugger via verify- ing runtime execution step-by-step. arXiv preprint arXiv:2402. 16906, 2024. URL https:
Qihao Zhu, Daya Guo, Zhihong Shao, Dejian Yang. Peiyi Wang, Runxin Xu, Y Wu, Yukun Li, Huazuo Gao, Shirong Ma, et al. Deepseek-coder--2. Breaking the barrier of closed-source models in code intelligence. arXiv preprint arXiv:2406. 110.:114.6.1111,, 2024.
Terry Yue Zhuo, Vu Minh Chien, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, Simon Brunner, Chen GONG, James Hoang, Armel Randy Zebaze, Xiaoheng Hong, Wen-Ding Li, Jean Kaddour, Ming Xu, Zhihan Zhang, Prateek Yadav, Naman Jain, Alex Gu, Zhoujun Cheng, Jiawei Liu, Qian Liu, Zijian Wang. David Lo. Binyuan Hui, Niklas Muennighoff, Daniel Fried. Xiaoning Du, Harm de Vries, and Le- andro Von Werra. Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions. In The Thirteenth International Conference Learning Representations, 2025.
htw.eeeeewweeeeeeeeeeeeee http::/:///eeeeeeeeeeeeeee ew. foaeee//forumtt forum? (ew.rrummmdyyYyyyill
A THE USE OF LARGE LANGUAGE MODELS.
In the preparation of this manuscript, LLMs are utilized role was strictly limited to improving the grammar, clarity, and readability of the text. The LLMs are not used for research ideation, conducting experiments, or the generation any core scientific content. The authors take full responsibility for all content presented in this paper, including any text revised with the assistance of the LLM.
writing assistant. Its
B RELATED WORKS.
LLMs for Code-Related Tasks. L.Mss pre-trained extensive code corpora have demonstrated
remarkable capabilities various programming tasks, including code completion. code generation,
and code summarization (Li et al. 2022 Nijkamp et al. 2023 Roziere et al. 2023 Wei et al. 2023
Guo et al. 2024, Song et al. 2024 Wang et al. 2025). >. To enhance the accuracy of code generation, numerous techniques and frameworks have been proposed, such execution feedback and self- correction mechanisms (Chen et al. 20245) Zhong et al.) 2024 Moon et al., 2024)) Olausson et al.] 2024). However, despite these advancements, the research of LLMs to code optimization, field of both practical significance and considerable real-world challenges, remains underexplored in both academia and industry.
Code Optimization. With Moore's law losing momentum, program optimization has become central focus of software engineering over past few decades (Bacon al.) 1994 Kistler & Franz) 2003 Garg et al. (022). However, achieving high-level optimizations, such as algorithmic changes, remains challenging due to the difficulty in comprehending code semantics. Previous research has employed machine learning to enhance performance by identifying compiler transformations (Bacon jet al. 1994). optimizing GPU code (Liou et al.) 2020). and automatically selecting algorithms (Ker- schke et al. 2019). Recently, (Shypula et al. (2024) introduced the first C/C++ dataset designed for program efficiency optimization, with preliminary results demonstrating the potential LLMs in code optimization.
14

---

Published as a conference paper at ICLR 2026
C CATEGORIES OF OPTIMIZATION TYPES.
We categorize code optimization into three main categories: global algorithmic optimizations, local optimizations, and other optimizations.
This type of optimization involves altering the algorithm itself to achieve significant performance improvements. Such changes can effectively reduce time complexity and enhance the speed code execution. Examples include transforming recursive solutions into dynamic programming approaches, leveraging advanced mathematical theories, and restructuring complex data processing logic. These optimizations can lead to substantial gains in efficiency and scalability.
Global Algorithmic Optimizations:
Local Optimizations: These optimizations focus on improving specific parts of the code without changing the overall algorithm. They include enhancing I/O functions, optimizing read/write patterns to minimize runtime delays, and reducing computational complexity in certain sections of the code. By addressing these localized issues, programs can achieve more efficient execution and better resource utilization, ultimately leading to faster and more responsive applications.
This category involves general code cleanup and refactoring aimed at improving code readability, maintainability, and overall quality, Examples include removing un- necessary initializations and redundant code, cleaning up outdated comments, and organizing the code structure more logically.
Other Optimizations:
Problem-orienteed
User-oriented
Percent (%)
57.0
32.0
20
10.5
Global
Local
Other
Figure 7: LLM Analysis of the Optimization Types between Problem-oriente and User-oriented
Optimization Pairs.
D LLMs ANALYSIS ON OPTIMIZATION TYPES.
Figure presents the LLMs analysis optimization types between problem-oriented and user- oriented optimization pairs. GPT-4 identifies higher proportion of "global algorithm optimization" compared to human analysis. Upon further investigation, we find that this discrepancy is mainly due to GPT-4's tendency to categorize program pairs with significant changes "global algorithm optimization".
E DATASETS STATISTICS.
The statistical results of the PCO and PIE are shown in Table 5 We meticulously reviewed and ensured that any particular competitive programming problem appeared in only one of the train, validation, or test sets.
TRAINING DETAILS.
For Instruction/CoT prompt, we utilize the corresponding chat versions, while for fine-tuning, we employ the base versions of these L.MMs.
15

---

Published as a conference paper at ICLR 2026
Table Number of unique problem ids and pairs.
Dataset
Unique Problems
Pairs
PIE
1,474
77,967
PCO
1,474
77,967
Val
77
2,544
Test
41
978
We fine-tuned the CODELLAMA (13B), DEEPSREKCODER (7B, 33B), and QWEN2.5 10nn2255-Cr -CDDER (7B,
32B) models using LLLMA--FACTOR (Zheng et al. 2024 on a server equipped with 8 A10 GPUs (NVIDIA A100 80GB). During the fine-tuning process, employed LoRA (Hu et al. 2022 (with lora_ lora_rank-e rank=8 and lora lora_targeel target=all), and for both the PIE and PCO datasets, we trained the LLMs for only 2 epochs. The largest model, Qwen2.5-Coded
required approximately 48 GPU hours (8 GPUs x 6 hours) to complete fine-tuning on the PCO/PIE dataset (78 pairs). All experiments were conducted using AdamW (Loshchilov Hutter 2019) optimizer with an initial learning rate 5e-5.
G EXPLANATION OF SPEEDUP METRIC.
For the SPEEDUP metric, we adopted the same definition in PIE (Shypula et al.) 2024) without mod- ification. The rationale behind assigning 1.0x to failures is that code optimization cannot guarantee 100% correctness, as previously mentioned. Therefore, if the optimized code produces incorrect results, users in practice would discard it and revert the original version effeecivllyyy meaning speedup was achieved. Hence, we assign 1.0x SPEEDUP for failures to reflect this scenario.
H DISENTANGLING PERSPECTIVE AND SELECTION EFFECTS.
User-oriented) from the effect of selection (top-speedup vs. random), we have conducted new controlled ablation study. We designed and trained the following three datasets using the QWEN2.5-CODER 7B and identical hyperparameters to ensure a fair comparison:
To rigorously isolate the effect of the perspective (Problem-oriented
PIE (Original): Serves as our baseline, representing the user-oriented perspective (78K pairs).
PCO-Random (New Control): To isolate the pure effect the perspective, for each problem, randomly sampled the same number of pairs from the problem-oriented optimization pair pool as are present for that problem in the PIE dataset. This ensures that PCO-Random and PIE are perfectly matched in terms of the number of pairs and the specific problems covered, with the perspective being the only variable (78K pairs).
PCO Sco-Top-Speedup (Original PCO): Our initially proposed method, which selects the pairs with the highest speedup for each problem to form the PCO dataset (78K pairs).
Table 6: Comparative Results of Different Optimization Perspectives and Selection Strategies.
BEST @ 1
QWEN2,5-CODER 7B
% OPT
SPEEDUP
CORRECT
PIE
26.96%
2.80x
41.21
PCO-Random
49.55%
4.56x
53.23%
PCO-Top-Speeduy 54.83%
4.73x
56.26%
From Table 6 the comparison between Pan-Random and PIE demonstrates clear advantages of the problem-oriented perspective. Even with random selection from the problem-oriented pool, the model achieves substantially higher performance: %OPT improves from 26.96% to 49.55%
16

---

Published as a conference paper at ICLR 2026
SPEEDUP increases from 2.80x to 4.56x, and CORRECT rises from 41.21% to 53.23%. These improvements decisively show that the problem-oriented perspective itself the primary source of gains, while selection bias toward high-speedup pairs plays only secondary role. The added value of the selection strategy is evident when comparing PCO-Top-Speedup with PCO-Random. The full PCO-Top-Speediee
method yields further performance improvements, indicating that within the diverse landscape of the problem-oriented perspective, consciously selecting pairs with larger speedups can better unlock the model's potential. This represents meaningful refinement, building upon the foundational gains achieved through the perspective shift.
I PRIMARY REASONS FOR REMAING FAILURES.
We conducted systematic analysis of optimization failures. Among 100 optimized programs that failed the test suite, we identified three representative failure modes; the results are shown in Table
Compilation failures (syntax type errors).
Successful compilation with I/O-format issues, which we could manually correct to pass the tests. Semantic errors, ie., the optimized code compiles but behaves incorrectly.
Table Failure mode analysis.
Failure Mode
Percent
Failed compile (syntax/type errors) Compiled, semantic right but input/ouipu format failure Compiled, semantic wrong
16%
31 %
53%
Notably, Table(]reveel that roughly half of the failures fall into the third category: the model failed to fully and accurately capture the original code's semantics during optimization. This suggests that current LLMs still have blind spots understanding high-level program intent.
J GENERALIZABILITY BEYOND C/C++.
To evaluate the cross-language applicability of the problem-orienter perspective and the Anchor Ver- ification Framework, we replicated the core experiments on Python. We constructed the PIE/PCO dataset (Python version) from CodeNet, following the same methodology for C/C++. Since Python is incompatible with the gem5 simulator, we employed cProfile for fine- fine-graing rreegrained runtime analysis. The dataset contains 58,327 training pairs (PIE-Python, PCO-Python), 1,832 validation pairs, and 756 test pairs. The results are shown in Table S
Table 8: Fine-Tuning Results for LLMs PIE and PCO (Python Version) with BEST @ 1.
BEST @ %OPT
Python Version
LLMs
SPEEDUP
CORRECT
PIE
DEEPSEEKCODER 7B
45.18%
2.41x
70.15%
PIE
QWEN2.5-CODER 7B
48.35%
2.65
72.80%
PIE
QWEN2.5-CODER 32B
53.50%
3.12x
76.04%
PCO
DEEPSEEKCODER 7B
63.26%
4.05
79.41%
PCO
QWEN2.5-CODER 7B
76.18%
4.81
83.33%
PCO
QWEN2.5-CODER 32B
80.05%
5.35
89.27%
The problem-orient perspective yields substantial improvements in Python. With QWEN2.5- CODER 32B, %PT improves from 53.50% to 80.05% and SPEEDUP increases from 3.12x to 5.35x. The higher correctness rates compared to C++ align with observations that LLMs typically demonstrate better comprehension of Python semanties. These results confirm that the benefits of
17

---

Published as a conference paper at ICLR 2026
the
perspective are language-agnostic. We further evaluated the Anchor Verifica- tion Framework using DEEPSEEK- V3 to refine outputs from "QWEN2.5- 32B fine-tuned on PCO", the results shown in Table g
Table 9: Result of Anchor Verification Framework and compared methods with DREPSERK- V BEST @ under the outputs from "QWEN2.5-CODER 32B fine-tuned on PCO (Python Version)".
BEST@1
DEEPSEEK- V3
%OPl
SPEEDUP CORRECT
Base (w/o refinement)
80.05%
5.35x
89.27%
Self Debugging 81.57%
5.43
90.32%
Direct Test Generation
81.94%
5.56x
92.83%
Anchor Verification 83.32%
5.78x
95.35%
The Anchor Verification Framework achieves the best performance, significantly enhancing cor- rectness. This demonstrates that the core principle guileg functionally correct but slow code as trusted anchor for test case peerrationnreprrsen general and effective strategy for code opti- mization across programming languages.
K COST-BENEHT ANALYSIS OF BEST @ K STRATEGY.
The BEST @ strategy offers explicit control over the trade-off between performance and compu- tational cost. As demonstrated in Table TO] detailed scaling results for QWEN2.5- 32B on PCO reveal a clear pattern: while computational cost (measured in token usage) increases linearly with k performance improvements exhibit diminishing returns.
Table 10: Performance-com cost scaling for BEST@K.
PCO QWEN2.5-CODER 32B
% OPT SPEEDUP
CORRECT
BEST@
58.90%
5.22x
61.55%
BEST @ 2
66.41% %
5.94x
67.95%
BEST
70.71%
6.16x
72.24%
BEST @
73.57%
6.45x
74.90%
BEST @5
76.44%
6.75x
77.46%
BEST @ 6
78.58%
6.96x
79.81% %
BEST 7
80.11%
7.13x
81.24%
BEST @8
80.77%
7.22x
83.03%
This observation provides practical guidance for deploying the strategy in real-world scenarios:
For cost-sensitive production environments, BEST @1 1 delivers substantial improvements with minimal inference cost, representing the most efficient operating point.
When computational resources are abundant, increasing continues to enhance perfor- mance, though the marginal benefits decrease progressively. This allows practitioners to flexibly balance performance and cost according to specific requirements and constraints.
L PRACTICAL COST
To investigate the overhead of the Anchor Verification Framework, we measured the corresponding time cost for each stage. During the Anchor Verification Framework process, the overhead is almost identical to that of "Direct Test Generation" because the only difference is that Anchor Verification asks the LLM to produce only the test-case inputs, whereas Direct Test Generation requires the I.M produce both inputs and outputs. All other stch understanding and explaining
18

---

Published as a conference paper at ICLR 2026
Table 11: Average runtime overhead per method.
Time Cost
Query
Execution (testcase output)
Execution (testcase)
Refinement
Self-Debugee De-ugginuggg
13.68
Direct Test Generation
9.27
0.23
15.85
Anchor Verification
7.24
0.22
0.22
15.16
the code-remain the same. Furthermore, we have broken down the entire pipeline into individual steps and measured the corresponding per-stage time cost, shown in the Table below:
From the measurement results, can be seen that the primary time overhead for different methods attributed to the invocation of the GPT-4o API, whereas the local sandbox environment for executing the code is relatively significantly faster in comparison. Meanwhile, the Anchor Verification Frame- work relies the code can produce the correct output within a finite time, the generated test cases are considered valid and can be used for subsequent refinement.
the correctness of the slow code and has high tolerance for its speed-as long as
However, going a step further, for scenarios involving practically intolerable slow code execution, several intervention strategies remain available. Two practically viable approaches include: (1) Exe- cution Time Threshold: enforeing configurable time budget that automatically discards test inputs exceeding this limit maintain practical verification overhead; (2) Strategic Test Input Selection: implementing intelligent sampling of LLM --gennerated inputs-such as prioritizing critical execution paths or boundary cases maximize verification value while minimizing execution cycles. These methods preserve the Anchor Verification Framework's 's core advantages while effectively handling substantially slow code.
M THE PROMPTS OF ADAPTING LLM ON OPTIMIZATION PAIRS.
In this section, we present the prompts for adapting the LLM to optimization pairs. The instruction prompt is shown Figure g the CoT (Chain Thought) prompt shown in Figure and vLLM inference prompt is shown in Figure I0
Given the program, generate efficiency improvement strategy to enhance its performance.
Given the program below, improve its performance:
### slower program: (slow_code)
### Program: {slow_code}
338 strategy: LLMs generated potential strategy.
$88 Optimized Version:
888 optimized version:
Figure 8: Instruct Prompt.
Figure 9:
Prompting.
N FINE-TUNING ON GED-STRATIFIED SUBSETS
To investigate whether nigh-disparin code pairs hinder learning in the problem-oriented dataset, we conducted a controlled ablation study using Graph Edit Distance (GED) the stratification criterion. Three specialized training subsets were constructed from the PCO dataset, each representing distinct characteristics of optimization pairs:
19

---

Published as a conference paper at ICLR 2026
Given the program belcw, + improve its performance:
##N Program: (slow_code)
### Optimized Version:
Figure 10: Inference Prompt.
cubarraysum (int- nums, numaSize,
Node- new_node key, val) Node (Node ) mal lod (sizeof (Noda) n->key keys n-2val valy d->next NULE? return n2
k)
count Or
for (int i 0g numaSizer 411)
int aum D3
numsdize; (1)
sum + numa (5]; (aum ++oount)
#define BASI_SI2E 200003
Node (HASS_ SIX3];
subarraySun, numa, int numaSize, int
k)
int count - 0, sun 0;
(a) PCO: Slow Code.
for (int i = 02 1 HASA ++1) toble(i] NOLT,
put (E, 11; prefix_eum(0]
//
for (int i - 0; 1 nuna0izer (12) 4
[i];
count += get (aum - k); put taum, 1);
(b) PCO: Optimized Code.
0f ++2)
++1)
for (int = 3 m; ++]!
for (int = 1 my ++3) soant (*Ad", sali)()));
acanf ("Sa", salil :11;
while (q--)
long long pre[1005] for (int
(0))
int xl,
y2; scant kd Rd Sc*, 4x1, 681,
ny ++11
for (int 1 - 1 <= my ++1l
sy2);
pre[i] prel1 1101 [r-11]
--x1; --y1; --x2; -- 11
index
11-11 a[i-1)(j-1];
long long
for (int x1; <= x2; ++1)
for (int
y2t ++d)
while Iq--) int xl, yl, x2, y2; ld", sx1, syl, 4x2, 4y2);
sum 1- a 11.1
("S1ld''" gum)
scenf
long long sum pre(x2] [y2]
pre(x1-11iyg) ly2] pre [x2] [yl-1]
+ pro (x1-1] [ (yl-1);
(c) Practical Slow Code,
print ("Slid\a", sum);
(d) Practical Optimized Code.
Figure 11: Case of learning edit patterns.
PCO-High-GED: For each problem, we selected the top 40% of optimization pairs with the highest Graph Edit Distance (GED), representing major global transformations.
20

---

Published as a conference paper at ICLR 2026
For each problem, selected the top 40% of pairs with the lowest GED, representing minor, localized optimizations.
PCO-Low-GED:
PCO-Random:
For each problem, we randomly selected 40% of pairs as balanced baseline controlling for dataset size.
Table 12: Optimization Performance on GED-Stratified PCO Subsets.
BEST @ 1
QWEN2,5-CODER 7B
%OPT
SPEEDUP
CORRECT
(CO-High-GEDD
46.23%
4.48
50.43%
PCO-Low-GEII
36.49%
3.75
42.43%
PCO-Random 40.32%
4.11x
46.94%
We then fine-tuned separate QWEN2.5 SEDDERR 7B models on each subset using identical hyperpa- rameters and training procedures. The comparative results (Table 12) reveal two key findings:
1. High-GED pairs enhance rather than hinder learning: The model trained exclusively on high-GED pairs demonstrates superior performance across all metrics compared both the low-GED model (+9.74% %OPT, +0.73x SPEEDUP) and the random subset model (+5.91% %OPT, +0.373x SPEEDUP). This clearly indicates that while differences in vari- able declarations and readability exist in high-GED pairs, they do not fundamentally con- fuse the model. Instead, the model successfully learns to focus on the underlying algorith- mic improvements that drive performance gains.
2. Algorithmic innovation drives substantial performance gains: The consistent outperfor- mance of the PCO-High-GED model reveals that learning fundamental algorithmic trans- formations provides greater value than learning incremental, localized improvements. The model demonstrates the capability to abstract away surface-level differences in favor of recognizing deeper algorithmic patterns.
O LEARNING EDIT PATTERNS
To further investigate whether the PCO approach can distill effective algoritnnieimprovemenn pat- terns from pairs with large structural disparities, we conducted empirical case study. As shown in Figure II] within the PCO optmization pairs, a representative and efficient algorithmic paradigm is: rewriting a nested double for Σoop into a pattern of "prefix-sum preprocessing elimination of the inner loop". ", thereby removing the significant overhead introduced by the nested iteration.
() In the PCO method, common algorithmic paradigm shift boils down replacing the naive double for loops by prefix-sum + hash lock-up scheme. By utilizing the prefix sum sum [um[0... II] and a hash table record the occurrence counts of historical prefix sums, reducing the overall time complexity to O (n).
(ii) In practice, the same improvement pattern is also applied: matrix operations, 2-D prefix-sus with constant-time queries dramatically reduces the nested complex- ity of the original multilevel loops by first precomputing ing a prefix sum matrix pre [i] [i].
This demonstrates that the "edit" pattern (algorithmic optimization pattern) learned by PCO trans- ferable and robust, rather than merely conditional generation.
P PRACTICAL PERFORMANCE STUDY ON PHYSICAL HARDWARE
To further validate the optimization effectiveness beyond simulated environments, conducted performance measurements on physical hardware. This study aims to verify whether the perfor- mance improvements observed in gem5 simulations translate to real-world systems.
21

---

Published as a conference paper at ICLR 2026
Table 13: Performance Validation Physical Hardware.
Optimization Type
SPEEDUP (gem5)
SPEEDUP (Hardware)
Relative Error
Global (Dynamic Programming)
8.5x
7.1x
16.5%
Global (Greedy)
12.2x
10.3
15.6%
Local (Loop Unrolling)
1.8x
1.5x
-1..7%
Global (Data Structure)
5.1x
6.2x
+21.6%
Local (Cache Optimization)
3.3x
2.8x
-15.2%
Global (Algorithm Change)
15,4x
12.8x
-16.9%
Local (Memory Access)
2.1x
1,9x
-9.5%
Average
6.9
6.1x
-11.6%
Experimental Setup. We executed test programs on server with 2x Intel Xeon Platinum 8468 CPUs (48 cores/socket) featuring 192 MiB 1.2 cache and 210 MiB L.3 cache, operating 3.1 GHz. All programs were compiled with GCC 9. 4 0 and 03 optimization flags, maintaining consistency with the gem5 experimental configuration.
Methodology. We randomly selected 20 optimization pairs from the test set, representing different optimization categories (including global algorithmic changes and local optimizations). For each pair, measured average execution time over 10 runs and calculated speedup on physical hardware.
Comparative results demonstrate strong agreement between simulated and hardware measurements (Table B3 Key findings include:
1. Consistent Optimization Effectiveness: All code optimizations that demonstrated signif- icant speedup in gem5 showed substantial performance improvements on physical hard- ware, confirming the real-world validity of the proposed optimization approach.
2. Strong Correlation: The Pearson correlation coefficient between gem5 and hardware speedups is 0.89, indicating that gem5 serves excellent predictor of relative perfor- mance trends despite architectural differences.
3. Systematic Performance Difference: The slightly lower speedups observed on hardware 11.6% on average) are expected, as gem5's timing model cannot fully capture all microar- chitectural features of modern Intel Xeon processors. However, this systematic difference does not affect the fundamental conclusion that the proposed optimization methods provide substantial performance benefits.
This hardware validation confirms that the reported performance improvements effectively translate to real-world systems, strengthening the practical significance of the optimization framework.
Q IMPLEMENTATION DETAILS OF THE ANCHOR VERIFICATION FRAMEWORK AND THE COMPARED METHODS.
Anchor Verification: In the Anchor Verification Framework, for the test case inputs in Stage we prompt the LLM to generate three test case inputs based on the "slow code", the detailed prompt as illustrated in Figure 12] In Stage and Stage 3, for compiling and executing both the "slow code" and "optimized code". we compile C++ programs using GCC version 9.4.0 with C++17 and the -03 optimization flag. In Stage 3. we leverage the verified test case sets. If an eиror occurs, we provide the error information to the LLM, allowing it to iteratively refine the optimized code based this feedback. The detailed prompt is shown in Figure 13
Self-Debugging: following the approach presented in et al. (2024b), the method instructs the LLM to provide line- line-by-line explanations of the generated program as feedback, functioning akin rubber duck debugging. In this process, the L.M is capable of autonomously identifying and rectifying bugs without requiring human intervention. The detailed prompt is shown in Figure 14
Direct Test Generation: The LLM generates complete test cases (including both inputs and out- puts) and utilizes synthetic test cases execute the optimized code, enabling iterative refinement.
22

---

Published as a conference paper at ICLR 2026
The prompt for generating complete test cases is shown in Figure while the iterative refinement prompt is the same as the one used Stage 3 of the Anchor Verification, as depicted in Figure 13
You are code expert, and your task is correct 4 the functicnally incorrect code based on test cases and execution feedback. Analyze the issues, apply the necessary fixes, and ensure the corrected code meets the expected funstionality and pass the testcase.
Given the program below,
please explain and analyze
its functionality. and provide 3 testcase inputs
that fully consider
boundary conditions and code coverage. Note that only the testcase inputs are required.
888 Incorrect Program: (code)
### Program: (slow_codc}
### Explanation: (explanation)
## Explanation:
(Your explanation here)
### Testcase: (Testcase)
#$$ Test case inputs: |Your testcase inputs]
*## #eedback from execution: (Feedback)
Figure 12: Anchor Verification Framework Stage
### Your corrected code versicn:
(Test Inputs Generation) Prompt.
Figure 13: Anchor Verification Framework
Stage 3 (Iterative Refinement) Prompt.
R RESULTS OF ANCHOR VERIFICATION ON PIE.
We conducted experiments using "QWEN2.5-CODER 32B fine-tuned on PIE" as the baseline and compared it with other methods. The results, shown Table 14] demonstrate that Anchor Verifi- cation consistently delivers the highest performance gains. On the DEEPSEEK- V3 backbone, we observed improvements in %PP (31.24% ~> 47. 28%).. SPEEDUP 2.95x->3.40x ), and CORRECT (46.52% + 65.32%). Furthermore, we found that the gains in optimization ratio and speedup brought by the Anchor Verification Framework's 's improvements significant as those observed in PCO. For example, on the DEEPSEEK-V V3 backbone, CORRECT increased by 18.8%, but SPEEDUP only improved by 0.45x. In contrast, on the PCO scenario, CORRECT increased by 12.99%, while SPEEDUP saw a larger improvement of 0.86x.
correctness on PIE were not as
S LIMITATIONS.
This paper focuses on optimizing the time efficiency given code, without considering other op- timization directions. However, in actual practice, there is a wide range of optimization avenues, such as memory optimization. Moreover, ensuring the complete accuracy of code optimization is multifaceted and intricate issue that deserves further exploration and research.
23

---

Published as a conference paper at ICLR 2026
Given the progran below, please explain and analyze its functionality, and generate three comprehensive test cases that thoroughly cover boundary conditions and all code paths. Each testcasc should include the input and the corresponding expected output.
Below a potentially
problematic C++ program.
Please provide line-by-line explanation
and correct any errors that may be present.
### Program: (program)
### Explanation:
### Program: (slow_code)
(Your explan anation here)
888 Revised Program: (Your revised program here)
338 Explanation: (Your explanation here)
### Test case: (Your testcase)
Figure 14: Self-Debugging Prompt.
Figure 15: The Prompt of Direct Test Genera- tion Method.
Table 14: Results of Anchor Verification and compared methods with QWEN2.5 5-DDERR GPT-4o, and DEEPSEEK- V3 on BEST @ 1. The baseline is the output of QWEN2.5-CODER 32B on PIE in
Table [
BEST@
LLMs
Methods
%0PP
A
SPEEDUP
CORRECT
A
Buseline (w/o refinement)
31.24%
2.95
46.52%
Self Debugging
35.69%
+4.45
3.02x
+0.07
53.74%
+7.22
QWEN2.5-CODER 32B
Direct Test Generation
38.74%
+7.50
3.08x
+0.13
57.49%
+10.97
INSTRUCT
Anchor Verification (Ours)
40.48%
+9.24
3.17x
+0.22
59.09%
+12.57
Self Debugging
37.47%
+6.23
3.06x
55.65%
GPT-4o
Direct Test Generation
39.64%%
+8.40
3.13%
+0.18
57 86%
+11.34
Anchor Verification (Ours)
42.50%
+11.26
3,32x
40.37
63 63.60%
+17.08
Self Debugging
40.61%
+9.37
3.23x
+0.28
59.62%
+13.10
DEEPSEEK- V3
Direct Test Generation
40.17%
+8.93
3.18%
+0.23
58.73%
+12.21
Anchor Verification (Ours)
47.28%
+16.04
3.40%
+0.45
65.32%
+18.80
T DETAILED EXAMPLES OF PERSPECTIVES.
AND PROBLEM-ORIENTED
We provide detailed examples, shown in Figure 16 Figure 17 Figure 18 and Figure 19 to
illustrate that the original PIE, program optimization pairs are constructed through iterative sub- missions and optimizations by the limited by the single programmer's thought patterns.
for the same programming problem, which can be
U CASE STUDY OF ANCHOR VERIFICATION FRAMEWORK.
We present three case studies to vividly illustrate specific examples of Anchor Verification, as de- picted in Figure 20 Figure 21 and Figure 22 These cases offer clear and intuitive understanding of how Anchor Verification Framework operates in practice.
24

---

Published as a conference paper at ICLR 2026
Finclude <iestream>
finclude <bits/stdo*t.hr using namespace std;
#include<cstddo> int int a [MAX]
#inolude cstdio.h> using namespace std;
typedef long 11;
#dofine long long typedaf sectorcint> v1;
main()
int
int main()
long long sum - 0; scanfi"'d", an);
int lengch:
const int INE - 1e18 1e18
azr [202000];
for (int 01 mj (++)
(202000] (01;
void s)lve()
11 temp = 0y
int
{
m 2147483647;
cin
scanf
1)
"can""""d", =length);
vi vin), pre (n); int mn INE, for (int = 0; <
sum -- a(i];
for (int
}
length: +41)
long long
c"anf("31d")
i++) cin >> v(i];
left, tight
(arr(i]);
pre[U] v[0];
left
ain 1.7
for (int = 1: < mi
right = a(n - 1];
[es arr(0];
(++) [r] v[')
long long
for (int i - 1; 1
pre(i 1];
righ: left sight
length; ++1) {
for (int
right leftr
res[i] rea
i--) [
left 0;
+ [r]
$ += vill
for (int i 0; n-2;
(mn,
itt)
for (int = 1: i<
aba (pre (1
left + a[i];
length; ++1)
a));
right sum left;
abs (res (length
left right
-1 resli
cout << mny
left right
right laft;
(temp, m);
if (temp min) min-temp:
signed main() { spead; int t 1;
printf ("SidApn m);
return 07
Dr min)s
whileit-1 solve();
return 0;
(a) userl, initialization version.
(b) userl, iteration version.
(c) another user submitted version.
The three submitted code solutions all address problem "p03661", which asks for split point in an array that minimizes the absolute difference between the sums of the two parts. Solutions (a) and (b) are different submissions from same user "u018679195" In (a), the prefix sum calculated first, then the minimum difference is computed from start to finish. In (b), the prefix sum also calculated first, but the minimum difference is computed from end to start, avoiding additional multiplication operations. Solution (c), from user (u3539191433 calculates the difference between the left and right sums in real-time, requiring only one pass through the loop. It be seen that solutions (a) and (b) only make local changes, while (c) constructs more efficient algorithm.
Figure 16:
25

---

Published as a conference paper at ICLR 2026
Pinclude <bits/stde++..r
Finclude <bits/stde*+.br using namespace std;
Finclude #imoludesalgorii using namespace std; const int MAxN-int (1e5+51; typedet long long 1.; #define INF (2e155 LL el, 62, uu s2 [MAXN] Eh ( c[5]; int main
using namespace std;
#define long long const int N = 105 M 3, inf 1e15;
#derine int long long
const int N - 1e5 1 5,
inf 1e15;
int [M], a[N], [N];
int dp [N] [M], a[N];
sign (int x) if 2) return -1; return
char op [
scan ""an""""]"d""""" scant (candi""1id",aas))
int Sign (int
getchar for for i=1;i<on-lpit-) soanf (*8af
ix $ 2) return -17
raturn 1;
int32 m)in(
ics: las::syn__wthhh wtt.aaccc.ttssttiiiiio.
("d" ch[1)=a[0);
cin.sie
int32_t ma m)in()
cout.tie(0),
for (int i 0;
cout.tie(0])
s1-a2- INF;
i++) for (int 0f
for (int i++) for (int 5 02 1 1++) (p]
for (LL i-1pi<om-17i+->
< Mj j++) 6p
if (th
-in";
as-=8a[1]]
int my cin >> n >> 2001;
= -inf;
s1-
1,
ny >> >> a[0];
22-=am(1]]
1tt) ein 25 opli) 50
for (int
a1-max a21;
afil;
i++) cin opli:
82 maxx 821
dp [p[0][0] a(0];
a(il;
for (int i 1: n;
(p[ = a
else
itt)
(int
as--sa [1];
1; sa 0: 3--1
i++) for (int ==
51-saz [1]]
if [op[i] 141]
1; 3- 0: 3--1
a2--68 [1]]
dolil - dpli
if [op[i] - 11"]
11ill + a(il
dolil 151 dpli
52-max (s1, =2)
(ign
1) a(i)
as-max (s2,
else if (3) (3)
Sign (1);
}
dp(i 110
else (3) 6pl1. LJ
1] a(t)
dp(1 - 1JD3
(i)
11 ati]
if 1 M
(i1e
dp/i1151
(1
M)
(c) another user submitted version.
(1))
dp(i]
11 111;
max (3p
do 11 1]1;
cout <c dp [G]
"An";
cout <c dola 11[0] 6c "An";
(a) userl, initialization version.
(b) userl, iteration version.
The above three code snippets all come from the problem "p03580", which involves max- imizing the evaluated value a given formula by adding an arbitrary number of pairs of parentheses and outputting the maximum possible value. (a) and (b) from the same user "u1821171064 both employing dynamic programming algorithms with a time complexity of O (N * M), where N the length of the sequence and M is the number of states. In (b). the number of states M is reduced, and input and output are optimized. (c) is from user "u863370423" and uses a greedy algorithm, which suitable for problems with fewer current states where the global optimal solution can be achieved through local optimization, with time complexity of O (N).
Figure 17:
26

---

Published as a conference paper at ICLR 2026
Pinclude <iostream>
finclude <bits/stde*t.h using namespace std;
finclude <estdio> #dorine int long long #define ioei (1, a) foz fint 0j (a)7 116)
#inclide seatring>
using namespace std; typedef long long LL;
#define int long long #define pb back #define aes::aya__wthh_stdaaa
#define a(2) for (int 1-0;iem:i11)
using nemespace std;
d[555] [535] (0), e[555] [555] (0);
rint ()
const int 509; vettor v[N 517
int n;
scanf ("slid", an)s return
int (int 1, int
if (1 > r) return 0z
int32 t main
(d(1) 1=
faster;
d[1] [e]:
int n,
void wint lint n) printf("slion n);
return d[l] [x] [x)]xx)
cin n >> p >> q:
int for (int 1, i p7
qu
qu(l
I, 1)z
i++)
signed main(1
ein >5 x 55 y7 x[x]-pb(yl2
int rint 1)
int rint
int main()
int Q rint ()
memset (d, -1, si)e
for (int
S(N [N 1];
int 47 ein 35 >> m gr
1tt)
dotimes IR, N 1)
sort (elilbbeginti v(s).end()1z
detimes (L, K
while (m--)
s[8] 0z
int 1, rj EF
dotimes M)
while (q--)
rint
c(1) [+]++]
cin >> x >>
int = rint (1)
ans Dj
[[]+
while (g { int 1, F7
for (int i
y7 it4)
dotimes 18, dotimen
ein 1 >> Fy cout << quil, r) << eadl;
upper b upper_bound( vti] ()gin
S + 1] [T. +- SIR
[1] 8131
v[1] (end y! beginn
1] - (T) dotimes 11, int rint (1
return 0z
int rint (1)
cout "An";
wint (5( S[P] (p]
(a) userl, initialization version.
S(e] [p! 19.1
return 0;
(b) userl, iteration version.
another user submitted version.
Figure 18: The above three code segments all come from the same problem "p03283", which deals with cumulative sum queries 2D matrix. (a) and (b) are different submission versions from same user "u8l 088166318222 1826". In (a), the problem is solved using recursion and dynamic programming. but the query time complexity is high, O (N2). In (b), the STL-provided binary search function is used, reducing the time complexity to O (N log(N)). (c) comes from another user "u281670674" and solves the problem using 2D prefix sum matrix. The preprocessing time complexity is O (N²), but the query time complexity for each query is O (1), making more efficient.
27

---

Published as a conference paper at ICLR 2026
#include <bits/stde+r.B
finclude <bits/stde*r.
Minclude #incirde<catdiio
using namespace std;
using namespace std;
using namespace std;
typedef long long 11;
inline void rd (int 6x) [
inline void rdlint ax)
#define zep n) for (int i
char chj
char chj
02 (n]) 144)
for(; (o Hidiggi (ett ())
for fidigit weggg//thhhheeeee wcw.getchhaaaeeooooooooo 13)
#dofine rap1 (4, n) for 1
for (xech- 1
(x=chh-1000 '0";
(n) 14+)
isdigit (chigotchar
isdagit (chageschar
x=x-10+oh-101;
x-x-10-ch-10';
int hist [30D032],
eat [300001];
const int cm 17; char [n(m), ct;
typedef long long Li;
typedef long long
const int MAXN 300005;
coast
300005;
inline int getint ()
int N, D, [MRXN], ont [MAXN];
int D, ent [MAXN];
int 0;
if (ci
16 > cm)
Lu sum [MAXN]
Lu sum [MAXA]
while [(ct
getcha ()) 101
int and [MAXN];
int ans [MAXN];
& . 13 + et 191
else while (lct +ai++)
inline bool chik (int k, int
inline bool (int K, int x)
>e '0 A
10 10
{
return sum[x]
ct 10';
int pos uppe:_bound(e
111-kex;
return Arl
1, + n x)
return [poa-1]
main())
const int
111- poatppptt)--ae +x 111+xxx;
idiin;;
char dn [dn],, A di - dni
for (int 1, x;
++i) (x),), trent [X],
int main()
risumicnt [x]]]][[]]]] [x]
int getinn ()
int main()
for (int 17 1
rep hist [gatint() repl ent (hist(AA]] 117
rd (N);
++1) sum(3] +=
(int x;
sum[i-1];
(11) cd(x), Hent [x];
int now 0;
(int 1:
for (int n: >-
300000; 111)
k)
ri, N 1) septi, k [i]( hist
if(cnt a[tin cnt
while (new a 45
cak now+ll)
sort ta 1, a nnnnn 1)3
+ ans [x] now;
int ruisek! M
(int
07
(+1) sum[i]
for (int - N; i >m 1,
sum(i-i] alils
for
i--)
int 0f
(i) prinsE("SdNe", ans()));
while thist 1) 1 ruisaki
for (int & nr k >m 17
--k) while (now < 66 chik (k. nowil))
hist (--k
(b) userl, iteration version.
+iner
int kei N ' ruiseki.
ans(k] now:
for (int i 17 Ny ++1) prinsfi"'dNa an)(i]);
for (int j = moc 1,
3 ket; (tm)
putinn (1);
mae kei:
}
(int 1 = man + 1;
(a) userl, initialization version.
<m Nr j++1
-di+ 10';
+di++ (\n
}
Ewzite (da,
dn,
stdout];
return 0;
(c) another user submitted version.
Figure 19; The above three code snippets all come from the problem "p02890", which requires calculating, for each possible K value (from 1 to N), the maximum number of times K cards with different numbers can be selected and removed from N cards. (a) and (b) are from the same user "u990400947" and utilize prefix sum calculation and searching. The latter employs condition check- ing with a time complexity of O (N * log)N)). (c) uses a difference array, reducing the time com- plexity to O (N).
28

---

Published as a conference paper at ICLR 2026
Optimized but incorrect Code
#include <stdio.h> #include <algorithm>
using namespace std;
int i, i, int main() scan ("Sddd",, sk);
for (o=1:11<=;; ("sd"
sort (++1,)+++));; prints pooddh a+n+1, +1))
return 0;
*Below is the Explanation of slow code and generated test case + inputs*
**Explanation:**
This code counts how many elements in an array greater than or 4 equal to given value Here the breakdown:
Input: Reads n (array size) and k (threshold value), followed by an array h of size
Sorting: Sorts the array in descending order.
Counting: Iterates through the sorted array and counts how many 4 elements are greater than or equal to k. Output: Prints the count.
**Test Inputs:**
Test case input: 5 5:
15 8 12 10 20
Test case input: 4
1
Test input:
7
7 777777
Verified Test cases **
** Test Cases** rest case input:
Optimi iniimized zed and Correct Code.*
5 10
15 12 10 20
Test case output: 4
#include <stdio. #include Kaigorithm> using namespace std;
Test case input:
int n, k, a[100005]; int main()
1 3
scanf(" &n, &k); for (i = 0; < nj itt) scanf ("Sd", aa[i]); sort (a, +n) printt n (Lower_bound/e a n, k) - a)); return 0;
Test case 2 output:
Test case input: 7
rest case output:
Figure 20: Case Study 1. The reason for the error is that the offset not calculated correctly. The correct fix is to calculate the index using lower bound(...) a.
29

---

Published as a conference paper at ICLR 2026
Optimized but incorrect Code
#include <cstdio> #include <algorithm> using std::ming #define MAXN 100003 int abs (int 2
if (z<0) return else return
int main (void)
int N, i,
int h [[MAN]], [[MAN]]; scan ("$d8d", & for (i=0;i<M;1++*)
{
scanf ("$d",,+t)
P[N-1]-0;
(h- for (i-N-3;1>=0
[pi]=minpp[i+1]] tabs (bli)-b(i++]), (bbs())-)h(1+2111
("ddt" return 0;
BBllow is the Explanation of slow code and generated test case inputs*
**Explanation:
This code solves dynamic programming problem find the minimum
+ cost to reach the n-th element from the first element in an 4 array, where you can jump up to k steps back at each position. Here the breakdown:
Input: Reads (array size) and (maximum jump distance), followed 4 by the array num.
Initialization:
dp array is initialized
large value, except de [0] and dpll], 4 which are set to (starting points with no cost)
De Transition:
For each position i from to n, it calculates the minimum cost to reach by considering jumps from positions (within [i-k, i-11).
The cost 4 added to the cost to reach j. Output: The minimum cost to reach the n-th clement (dp [n]) is printed.
absolute difference between num[i] num[j],
** Test Cases** Test case input:
5
13524
Test case input: 4.
10 20 10 30
Test case input:
6 3
1
2
3
5
30

---

Published as a conference paper at ICLR 2026
Verified Test cases
** Test Cases**
Test case input:
5 2
1 3 5
Test case output:
5
Test case input:
4
10 20 10 30
Test case 2 output: 40
Test case input: 6 3
2 3 5
Test case output: 5
Optimized and Correct Code**
#include <estdio>
#include <algorithm> #include <olimits>
using atd::ming idefine MAXN 100003
int abs (int 2
if (z<0) return
else return 2;
int main (void)
int K, i,
int h [MAXN], p [MAXN] scans ("$ddd"" &N, &K);
for (1=0;1sN;1++)
(
scanf(" h+i);
}
p[0] = 0;
for (i=1;
p[i] INT MAX;
for (j=1;je=K & 1-1ン-0;3+4)
(
pli] min( pli-d1 abs (h[i) h(i-31));
} ("ida""""""",,
return 0;
Figure 21: Case Study 2. The reason for the error is that the code does not properly handle the jump limit K, and the state transition logic incomplete, only considering the cost of adjacent positions and ignoring larger jump ranges. The correct modification is use double loop to dynamically update the minimum cost for each position by considering jumps up to K steps backward, thus fully addressing all possible jump scenarios.
31

---

Published as a conference paper at ICLR 2026
Optimized but incorrect Code
#inci ude<cstdio>
#incl [inclue<cssrrin>>
#include aee-uagoriiihhee
using namespace std;
int n, ans;
int [[10010];
int (
scanf ( ("$d", ,n)
for (int i-1;i<-n;iHt ("ad", sa
(1)
int mx=a[]], for (int i=2;icen:ith
if(ali]>m) mx=alál,id-it
if (mx<n-1) break; ans+-mx/n;
[id]s-n:
for (int i-1;i<=n;1+H
if(i!=id) a[i]+=mx/n;
}
printf ("Sd)n",ans))
BBelow is the Explanation of slow code and generated test case inputs*
*Explanation::
The code simulates a process where an array of size n is repeatedly modified until the maximum value in the array is no greater than n-1. The process involves the fellowing steps:
Input: The code reads the size of the array n and the elements of s the array a.
Main Leop: The code enters an infinite loop that centinues until the maximum value in the array is less than equal to n-1. In
4 each iteration:
The maximum value maxn in the array and its index id are identified.
If maxn is less than equal to n-1, the loop terminates. Otherwise:
The value at a[id] is updated to maxn $ (the remainder when maxn 4 is divided by n).
All other elements in the array are incremented by maxn (the quotient when The operation count ans inerenented by maxn n. Output: The total number of operations ans is printed.
is divided by
Test Cases**
Test input:
2
0 7
Test case input:
4
8
0000
Test case input:
4
3
32

---

Published as a conference paper at ICLR 2026
Verified Test cases
Test Cases*
Test case 1 input:
2
0
Test output:
Test case input:
4
8
Test case output:
2
Test input:
4
1 3
Test case 3 output: 9
Optimized and Correct A
#inciudeccstdio>>
sineiudo<estring>
finel waw-oldoooorttmmm
using namespace std;
int ans; int [110010];
int main()
scan ("$d", an);
for (int i-1;i<mn;i+4) ("td",
while
int mx]a [d],
for (int i-2;
if(=]i]>mx) mx=a(i)),d=i7
(mx<n) break; ans+=mx/n; a [[id]s=n;
for (int i=1;1<=n;1++) if(i--id) [[i]+=mx/n
print "rint=""$dAn"" ("&d\n", ans);
return 0;
Figure 22: Case Study 3. The error is that the termination condition used ma < 1, which prematurely stopped the loop, while the correct condition is mz < ensuring the loop only stops when maximum value is less than n.
33


Reviews:
[{"review_id": "0Y2csXxLbW", "reviewer": "Reviewer_5n4Z", "summary": "The paper argues that current LLM code-optimization datasets (e.g., PIE) are user-oriented—built from each programmer’s iterative submissions—so they mostly capture small, local improvements. It proposes a problem-oriented construction (PCO): pool all (functionally correct) submissions for the same problem across users, sort by runtime, and form optimization pairs along this global trajectory.", "questions": "* How does PCO perform on multi-file repos, build systems, or tasks requiring library calls and I/O patterns? Any results beyond single-file competitive problems or beyond C/C++\n\n* If PCO pairs were randomly selected (or matched by structural/semantic distance) rather than top-speedup, do gains persist with similar magnitude? Can you run a controlled ablation to isolate perspective vs. selection effects?\n\n* What are the GPU hours and runtime overheads for PCO finetuning and Anchor Verification (per iteration)? How does BEST@k scale in cost vs. benefit for practical deployment?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "* The problem-oriented pairing is simple, scalable (pair count grows sharply with users per problem), and empirically yields more global, algorithmic improvements, which translate to strong %OPT/SPEEDUP gains after finetuning. \n\n* Anchor Verification cleverly reuses the slow reference to build verified test cases, outperforming self-debugging or direct test-generation baselines and improving %OPT, SPEEDUP, and CORRECT simultaneously.", "weaknesses": "* Evaluation centers on C/C++ competitive-programming style tasks compiled with -O3 on gem5. It’s unclear how PCO/Anchor Verification transfer to multi-file projects, diverse languages, library/API-heavy code, or system-level constraints.\n\n* To equalize counts, PCO keeps the top-speedup pairs per problem (to 78K), which may advantage PCO relative to PIE beyond perspective alone; more controls (e.g., random or stratified matching) would strengthen the causal claim.  \n\n* EST@k relies on sampling with k up to 8 and T=0.7; variance across seeds, compute/token budgets for finetuning, and wall-clock overheads (including executor/sandbox) are only lightly discussed.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "iLqcFdF1Fq", "reviewer": "Reviewer_VBou", "summary": "This paper introduces two primary contributions to the field of code optimization using Large Language Models (LLMs). First, it proposes a \"problem-oriented\" perspective for constructing optimization datasets, a departure from the existing \"user-oriented\" approach. Instead of creating optimization pairs from the iterative submissions of a single programmer (which often leads to local, incremental improvements), the proposed method sources solutions from multiple programmers for the same problem, creating more diverse and algorithmically significant optimization trajectories.\nSecond, the paper identifies and addresses the \"optimization tax,\" a phenomenon where LLMs improve code efficiency at the cost of functional correctness. To mitigate this, it introduces the \"anchor verification framework,\" which leverages the original, inefficient but correct code as a \"gold-standard anchor.\" This anchor is used to generate a set of verified test cases, which then provide execution feedback to iteratively refine the LLM's optimized code, significantly improving its correctness. The authors conduct extensive experiments on multiple state-of-the-art code LLMs, demonstrating that both the problem-oriented perspective and the anchor verification framework lead to substantial improvements in optimization ratio, speedup, and correctness.", "questions": "see weakness", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "- Novel and Intuitive Core Ideas: The two central contributions are well-motivated and insightful. The shift from a \"user-oriented\" to a \"problem-oriented\" perspective is a simple yet powerful reframing that directly tackles the issue of limited diversity in optimization strategies. The \"anchor verification framework\" is a practical and clever solution to the critical problem of correctness in automated optimization.\n- Comprehensive and Rigorous Evaluation: The paper's empirical evaluation is a significant strength. The authors don't just present final numbers; they validate their hypotheses through multi-dimensional analysis, including structural (Graph Edit Distance), semantic (t-SNE embeddings), and human-led analysis to demonstrate the superior diversity of the problem-oriented dataset.\nStrong and Significant Empirical Gains: The experimental results are impressive and consistently support the paper's claims. The performance lift from the user-oriented (PIE) to the problem-oriented (PCO) fine-tuning is substantial across all metrics. Furthermore, the anchor verification framework provides an additional, significant boost, particularly in the crucial \"Percent Correct\" metric, validating its effectiveness.", "weaknesses": "- The experiments are conducted on the PIE and PCO datasets, which are derived from competitive programming problems on CodeNet. While this is a suitable domain for studying algorithmic optimization, it raises questions about the generalizability of the findings. Real-world software optimization often involves different challenges, such as I/O bottlenecks, memory management, API usage, and interaction with large codebases, which are not well-represented in this setting. The effectiveness of the proposed methods in these more common software engineering domains remains unevaluated.\n- Reliance on Simulated Performance Metrics: The paper relies on the gem5 CPU simulator for benchmarking execution time and calculating speedup. While simulators offer a controlled and reproducible environment, their performance characteristics can diverge from real-world hardware, especially concerning complex interactions like caching, memory bandwidth, and modern CPU microarchitectures. The performance gains, while significant in simulation, might differ on actual hardware. Including even a small-scale study on physical hardware would strengthen the claims of practical performance improvement.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "lPtFYdCLCY", "reviewer": "Reviewer_sxtm", "summary": "This work tackles the challenge of LLMs in generating optimized code. Since the core idea of LLM-based code performance optimization is to construct a good dataset of pairs of code before and after optimization, called optimization pairs, this work proposes an alternative approach to collect this type of benchmark. Instead of collecting optimization pairs as code snippets from a single software developer across multiple steps of optimization, this work constructed pairs of code from multiple programmers with the same coding problem. The second contribution of this work came from the observation that when optimizing the code, LLM models have to sacrifice correctness in many cases, called “optimization tax”. To solve the challenge, the authors propose an anchor verification framework to generate tests for output code by testing the input “slow” code. The experiment was done with the fine-tuning process performed on CodeLLama, DeepSeekCoder, and Qwen, and with the anchor verification performed on Qwen2.5-Coder, GPT-4o, and DeepSeek-V3. The accuracy shows that the fine-tuning process with a problem-oriented perspective can significantly optimize the input code compared to user-oriented data collection. The anchor verification framework shows improvement over the self-debugging and direct test generation approach in improving code correctness.", "questions": "- Can you provide an ablation study to see the cases that the PCO dataset collection collects pairs of code with high graph edit distance and vice versa (show a case of Figure 2)?\n- An algorithm to eliminate low-quality coding pairs for PCO is needed.\n- Does your dataset contain coding problems with approximated output, such as [3]?\n\n3. https://github.com/Exorust/TorchLeet/blob/main/torch/easy/rnn/RNN.ipynb", "limitations": "", "rating": 6, "confidence": 4, "soundness": 2, "presentation": 4, "contribution": 3, "strengths": "- The paper is well-written.\n- The idea of a problem-oriented perspective is sound and clear. It can help LLMs to learn how to optimize code by different coding styles.\n- Valid approach to ensure code correctness by anchor verification.", "weaknesses": "- While this work has considerable potential for improvement, a primary concern from the reviewer is that one drawback of problem-oriented data collection is that the dataset may contain pairs of code that are too dissimilar, despite solving the same coding problem. For example, the proposed strategy of data collection can produce code pairs that differ significantly in terms of variable declaration and readability level, which may increase the risk of confusing the LLMs during fine-tuning.\n- While the dataset was collected from a coding interview, it’s very likely that there were an existing dataset that already contained test cases, such as XCodeEval [1]. I suggest that authors consider evaluating this dataset.\n- In some problems like “implementing a torch model and extracting the loss function”, the test outputs, which are usually loss numbers from 0..1, it’s very likely that with the same input, outputs of the slow code and optimized code are slightly different. The proposed anchor verification framework does not handle this case.\n- To evaluate the code correctness, there are other coding perspectives, such as readability or coding style [2]. The anchor verification framework didn’t consider these perspectives\n\n1.XCodeEval: xCodeEval: A Large Scale Multilingual Multitask Benchmark for Code Understanding, Generation, Translation, and Retrieval\n2. Aligning Large Language Models to Coding Preferences", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "x12L8DGqiv", "reviewer": "Reviewer_wCBt", "summary": "This paper investigates the task of code optimization using LLMs, specifically focusing on reducing execution time. The authors propose two core contributions:\n\n1. Problem-Oriented (PCO): The authors point out that existing code optimization datasets are User-Oriented, constructed by collecting iterative submissions from the same programmer for the same problem to form optimization pairs. They argue that this approach constrains LLMs to local performance improvements and overlooks global algorithmic innovations. As an alternative, this paper proposes a \"Problem-Oriented\" perspective, which pools solutions from all programmers for the same problem and sorts them by execution time. This method constructs an optimization trajectory that encompasses a more diverse range of ideas and algorithmic strategies.\n\n2. Anchor Verification Framework: The authors discovered that as LLMs pursue higher efficiency, the correctness of the optimized code tends to decrease, a phenomenon they term the \"optimization tax.\" To mitigate this issue, they propose an \"Anchor Verification\" framework. Experimental results show that an LLM fine-tuned on the problem-oriented PCO dataset achieves significant improvements in both optimization rate and speedup ratio compared to one fine-tuned on the user-oriented PIE dataset. Furthermore, applying the Anchor Verification framework further enhances all metrics, especially the correctness rate , demonstrating its effectiveness in alleviating the \"optimization tax.\"", "questions": "Please refer to the Weaknesses section. If authors can address my concerns, I would be grateful and will raise my score. :-)", "limitations": "", "rating": 4, "confidence": 3, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "1. The shift from a \"user-oriented\" to a \"problem-oriented\" perspective is a novel and intuitively sound idea. It directly addresses a clear limitation of prior work -- a single programmer's cognitive inertia. This new perspective not only better aligns with the collaborative nature of real-world code review and refactoring but also, as the authors demonstrate, genuinely produces more diverse data.\n\n2. The paper does not merely propose PCO and present the results; it provides strong supporting evidence through \"structural analysis,\" \"semantic representation analysis,\" and \"manual and LLM-based sampling analysis.\" These analyses collectively confirm that PCO optimization pairs indeed involve more global, structural algorithmic changes, which enhances the quality of the dataset.\n\n3. The \"optimization tax\" is a real and critical challenge when applying LLMs in multi-constrained domains like code. The authors identify it as the primary performance bottleneck for the model after PCO fine-tuning. The \"Anchor Verification\" framework is an elegant solution that creatively leverages the \"slow code\" as a \"golden standard\"—a unique asset in this specific task scenario. This is more reliable than relying on the LLM itself to generate test cases (as in the \"Direct Test Generation\" method) or self-debugging, a fact confirmed by the experimental results.", "weaknesses": "1. I have some concerns about the generalizability of PCO. The core of PCO relies on obtaining multiple valid submissions for the same well-defined problem from multiple programmers. While this data is abundant on programming contest platforms, it is rare in real-world software engineering. In a typical project, it seems unlikely to find 10 programmers solving the exact same problem with 10 different algorithms. Could the authors discuss the application of this approach in such real-world scenarios?\n\n2. The entire Anchor Verification framework is built on the core assumption that the \"slow code\" is \"functionally correct.\" Although the paper mentions that the dataset filters out incorrect submissions, the specific process for this is not entirely clear to me. What is the concrete procedure for ensuring this functional correctness in practice? If this \"anchor\" itself contains undiscovered flaws, how would that impact the reliability of the verification framework?\n\n3. The paper claims the overhead of Anchor Verification is \"almost the same\" as direct test generation because the main cost is the LLM API calls. However, this conceals the premise that the \"slow code\" must execute \"fast enough.\" If the \"slow code\" is extremely slow, executing it even on a few test cases could represent an unacceptable overhead. The paper touches on this, but I would appreciate a more detailed discussion on this point.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)