Paper deep dive
Beyond Pass-by-Pass Optimization: Intent-Driven IR Optimization with Large Language Models
Lei Qiu, Zi Yang, Fang Lyu, Ming Zhong, Huimin Cui, Xiaobing Feng
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 7/20/2026, 11:59:45 PM
Summary
The paper introduces IntOpt, an intent-driven IR optimization framework that decouples high-level optimization intent from low-level transformations. Unlike traditional pass-by-pass compilers or end-to-end LLM optimizers, IntOpt explicitly formulates, refines, and realizes optimization intent through a three-stage pipeline. This approach enables globally coordinated transformations, achieving 90.5% correctness and significant speedups over state-of-the-art LLM-based optimizers and LLVM-O3.
Entities (8)
Relation Signals (9)
IntOpt → consistsof → Intent Refinement
confidence 95% · INTOpt organizes IR optimization into three stages: intent formulation, intent refinement, and intent realization
IntOpt → consistsof → Intent Realization
confidence 95% · INTOpt organizes IR optimization into three stages: intent formulation, intent refinement, and intent realization
IntOpt → consistsof → Intent Formulation
confidence 95% · INTOpt organizes IR optimization into three stages: intent formulation, intent refinement, and intent realization
IntOpt → uses → GPT-5
confidence 92% · INTOpt leverages GPT-5 (OpenAI, 2025) and its pre-training knowledge to explore optimization opportunities
IntOpt → outperforms → LLVM-O3
confidence 90% · surpassing modern compiler with the -O3 option on 37 benchmarks with speedups of up to 272.60x
IntOpt → uses → LLM Compiler FTD 13B
confidence 90% · We fine-tune LLM Compiler FTD 13B ... to obtain the optimization-specialized LLM
LoopVectorizePass → requiresanalysis → LoopAnalysis
confidence 85% · LoopVectorizePass requests loop-structure and target-specific analysis ... LoopAnalysis
LoopVectorizePass → requiresanalysis → TargetLibraryAnalysis
confidence 85% · LoopVectorizePass requests loop-structure and target-specific analysis ... TargetLibraryAnalysis
LLM Compiler FTD 13B → trainedon → IR-OptSet
confidence 85% · we collect a diverse set of IR programs from IR-OptSet ... We fine-tune LLM Compiler FTD 13B ... on D train
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Modern compilers optimize programs through a sequence of modular passes over intermediate representations (IR). While this pass-by-pass paradigm offers engineering benefits, it suffers from a pass coordination problem: locally beneficial transformations may block more profitable optimizations in later stages. This limitation stems from the lack of an explicit notion of optimization intent, defined as a holistic strategy for coordinating multiple transformations toward a global performance objective. Recent LLM-based approaches formulate IR optimization as an end-to-end generation task, thereby avoiding the traditional pass-by-pass structure. However, optimization intent remains implicit in these methods, forcing models to jointly infer optimization strategy and generate low-level transformations, which limits both correctness and performance. We propose IntOpt, the first intent-driven IR optimizer that explicitly separates high-level optimization intent from low-level analysis and transformation. IntOpt organizes IR optimization into three stages: intent formulation, intent refinement, and intent realization, enabling globally coordinated transformations. Experiments show that IntOpt achieves 90.5% verified correctness and 2.660x average speedup on 200-program test set, outperforming state-of-the-art LLM-based optimizers in both correctness and performance, and surpassing modern compiler with the -O3 option on 37 benchmarks with speedups of up to 272.60x.
Tags
Links
- Source: https://arxiv.org/abs/2602.18511v1
- Canonical: https://arxiv.org/abs/2602.18511v1
Trouble viewing inline? Open PDF directly →
Full Text
87,708 characters extracted from source content.
Expand or collapse full text
Beyond Pass-by-Pass Optimization: Intent-Driven IR Optimization with Large Language Models Lei Qiu 1 2 Zi Yang 1 3 Fang Lyu 1 Ming Zhong 4 Huimin Cui 1 2 Xiaobing Feng 1 2 Abstract Modern compilers optimize programs through a sequence of modular passes over intermedi- ate representations (IR). While this pass-by-pass paradigm offers engineering benefits, it suffers from a pass coordination problem: locally benefi- cial transformations may block more profitable op- timizations in later stages. This limitation stems from the lack of an explicit notion of optimization intent, defined as a holistic strategy for coordi- nating multiple transformations toward a global performance objective. Recent LLM–based ap- proaches formulate IR optimization as an end- to-end generation task, thereby avoiding the tra- ditional pass-by-pass structure. However, opti- mization intent remains implicit in these meth- ods, forcing models to jointly infer optimization strategy and generate low-level transformations, which limits both correctness and performance. We propose IntOpt, the first intent-driven IR opti- mizer that explicitly separates high-level optimiza- tion intent from low-level analysis and transforma- tion. IntOpt organizes IR optimization into three stages: intent formulation, intent refinement, and intent realization, enabling globally coordinated transformations. Experiments show that IntOpt achieves 90.5% verified correctness and 2.660× average speedup on 200-program test set, outper- forming state-of-the-art LLM-based optimizers in both correctness and performance, and surpass- ing modern compiler with the-O3option on 37 benchmarks with speedups of up to 272.60×. 1. Introduction Modern compilers leverage intermediate representations (IR) to enable compilation that is independent of both programming languages and hardware architectures (Aho 1 SKLP, ICT, CAS, China 2 UCAS, China 3 Jiangnan Uni- versity, China 4 CUHK, China. Correspondence to: Fang Lyu <flv@ict.ac.cn>, Huimin Cui <cuihm@ict.ac.cn>. Preprint. February 24, 2026. et al., 2006; Lattner & Adve, 2004). By optimizing at the IR level, which abstracts away language- and hardware- specific details, compilers can improve the program exe- cution efficiency (referred to as “performance”) across diverse programming languages, target architectures, and application domains, ranging from traditional scientific com- puting (Moses et al., 2023; Bezanson et al., 2017; ̈ Ozen et al., 2018) to modern AI workloads with specialized tensor oper- ations (Lattner et al., 2021; Chen et al., 2018; Sabne, 2020). Consequently, designing effective IR optimization strategies has remained significant in compiler construction. However, the effectiveness of IR-level optimization is fun- damentally constrained by how modern compilers organize optimization. In practice, modern compilers decompose IR optimization into a sequence of passes, each implemented as a modular unit that targets a specific optimization, such as loop unrolling or constant propagation (Lattner & Adve, 2004; Stanier & Watson, 2013). These passes make deci- sions by analyzing optimization-related information derived from the IR (hereafter referred to as “analysis”) to assess whether a transformation will be beneficial. Although this pass-by-pass paradigm offers clear engineering benefits in terms of modularity and maintainability, it inherently suffers from a pass coordination problem: optimizations that are locally beneficial in early passes can inadvertently restrict or even prevent more profitable optimizations in later stages. As illustrated in Fig. 1(b), when the compiler optimizes the IR corresponding to the source code in Fig. 1(a), the LICM- Pass (loop-invariant code motion) hoistsD[i]fromL 3 to L ′ 2 to eliminate redundant accesses in the inner loop. While this transformation is locally beneficial, it prevents the Loop- InterchangePass from swapping theiandjloops to im- prove memory locality. More critically, because LoopInter- changePass cannot be applied, the subsequent LoopVector- izePass also fails to vectorizeL ′ 4 . As a result, the innermost loop retains a column-major access pattern forA[j][i] andB[j][i], which inhibits effective SIMD utilization and ultimately leads to degraded performance. This behavior arises from the lack of an explicit notion of optimization intent, which we define as a holistic strategy for coordinating multiple transformations toward a global performance objective. In compilers such as GCC (GCC, 1 arXiv:2602.18511v1 [cs.PL] 19 Feb 2026 Submission and Formatting Instructions for ICML 2026 for (i = 0; i < LEN; i++) for (j = 0; j < LEN; j++) A[j][i] = B[j][i] * D[i]; (a) Source code foo.c L 1 L 2 L 3 for (i = 0; i < LEN; i++) tmp = D[i]; for (j = 0; j < LEN; j++) A[j][i] = B[j][i] * D[i]; foo.l LICMPass Hoist D[i] L 1 ' L 2 ' L 3 ' L 4 ' LoopInterchange Pass LoopVectorize Pass Worse Perf. Worse Perf. foo . l (c) Existing LLM-based IR optimizers(b) Pass-by-pass IR optimization in modern compilers Better Perf. foo.l //double **A, **B, *D; Intent FormulationIntent RefinementIntent Realization Initial Strategy - Apply loop interchange (swap i and j) - Vectorize line L 3 to <2 x double> Refined Strategy Compiler Analysis Hardware supports AVX instruction set for <4 × double> processing ... Vectorize line L 3 to <4 x double> (d) Intent-driven IR optimizer (IntOpt) Optimized IR Generation Optimized IR Generation D[i] is invariant within the inner loop Figure 1. Comparison between existing IR optimization approaches and our INTOPT. 2026) and LLVM (LLVM, 2026a), this intent is implicit and fragmented across individual optimization passes. As shown in Fig. 1(b), LICMPass reduces memory operations, Loop- InterchangePass improves memory locality, and LoopVec- torizePass targets SIMD optimization. However, without explicit global coordination, individual passes cannot antici- pate how their transformations may enable or inhibit down- stream optimization opportunities (Kulkarni et al., 2006; Pallister et al., 2015). Recent advances in large language models (LLMs) (OpenAI, 2025; Anthropic, 2025; Daya et al., 2025) offer a promising way to address this limitation due to their strong program understanding and semantic reasoning capabilities. Prior LLM-based IR optimization methods (Cummins et al., 2025; Yang et al., 2025) formulate IR optimization as an end-to- end generation task that directly maps unoptimized IR to optimized IR, as shown in Fig. 1(c), avoiding the traditional pass-by-pass structure in compilers. However, this refor- mulation does not fundamentally resolve the core issue: optimization intent remains implicit, now hidden within a black-box LLM generation process rather than fragmented across individual passes in compilers. Consequently, LLMs are forced to simultaneously infer optimization intent and generate precise transformations, which makes it challeng- ing to guarantee both semantic correctness and consistent performance improvement. Our experiments in Sec. 4.2 empirically reveal substantial room for improvement. In this paper, we propose INTOPT, anIntent-driven IR Optimizer that reformulates the modern compiler optimiza- tion paradigm by decoupling high-level optimization in- tent from low-level analysis and transformation, thereby enabling globally coordinated transformations. INTOPT achieves this goal by deconstructing the IR optimization process into three stages: intent formulation, intent refine- ment, and intent realization. This pipeline mirrors how expert compiler engineers operate: first reasoning about optimization intent at a global level, then grounding it using program analysis to assess feasibility, and finally realizing it through concrete transformations (Muchnick, 1998). Our key insight is that, although existing compilers encode optimization intent implicitly within hand-crafted passes, these intents capture valuable domain knowledge that LLMs can learn and make explicit. Building on this, INTOPT first uses an LLM specialized in compiler optimization to infer an initial optimization strategy for a given program, repre- senting a structured form of optimization intent. This strat- egy is then grounded and refined using compiler analysis. For example, in Fig. 1(d), an initial strategy of vectoriza- tion with<2 x double>is refined to<4 x double> based on hardware-aware analysis. The refined strategy subsequently guides optimized IR generation, ensuring that transformations are globally coordinated. During the in- tent refinement and realization stage, INTOPT leverages GPT-5 (OpenAI, 2025) and its pre-training knowledge to explore optimization opportunities beyond those captured by existing compiler passes, as shown in Sec. 4.4. We evaluate INTOPT on 200 LLVM IR programs and achieve significant improvements over both end-to-end LLM-based optimizers and traditional compiler. Our re- sults highlight the importance of making optimization intent explicit for globally coordinated and semantically grounded IR optimization. We hope our findings will facilitate more research on intent-driven compiler optimization in this field. To sum up, our main contribution includes: •Intent-driven IR optimization framework. We propose the first intent-driven IR optimization framework that de- couples optimization intent from concrete IR transforma- tion, enabling more effective and reliable optimizations. •Compiler-knowledge-grounded IR optimization. We develop a novel approach that integrates structured com- piler knowledge to guide LLMs in IR optimization. • Comprehensive evaluation. INTOPT achieves 90.5% verified correctness and 2.660×average speedup on 200- 2 Submission and Formatting Instructions for ICML 2026 for (i = 0; i < LEN; i++) for (j = 0; j < LEN; j++) A[j][i] = B[j][i] * D[i]; foo.l Optimization -specialized LLM Initial Strategy S = a 1 , , a n L 1 L 2 L 3 Infer transformation actions that map <<IR>> to <<IR>> P opt P unopt Dataset Construction Intent (a) Intent Formulation Fine-tuning Apply loop interchange (swap i and j) Vectorize line L 3 to <2 x double> a 1 a 2 Compiler Knowledge Base GPT-5 Give the optimization strategy for ... ID: LoopInterchangePass Desc: Interchanges loops to ... Deps: LoopAnalysis ... ID: LoopVectorizePass Desc: Vectorize for SIMD... Deps: LoopAnalysis, TargetLibraryAnalysis Retrieve LoopAnalysis, TargetLibraryAnalysis (b) Intent Refinement Compiler Analysis LoopAnalysis: TargetLibraryAnalysis: Hardware supports AVX instruction set for <4 × double> processing ... Refined Strategy Optimized IR GPT-5 a 1 Apply loop interchange ... a 2 Vectorize line L 3 to <4 x double> Optimize IR... foo.l compiler analysis refined strategy Extract (c) Intent Realization Figure 2. Overview of INTOPT. program test set, outperforming state-of-the-art LLM- based optimizers by 7.0%-31.5% in correctness and up to 1.603×in performance, while also surpassing LLVM-O3 on 37 benchmark programs with speedups up to 272.60×. 2. Related Works Traditional IR Optimization in Compilers. Modern com- pilers such as LLVM (LLVM, 2026a) and GCC (GCC, 2026) perform IR optimization through a fixed sequence of passes (e.g.,-O3), where each pass applies a specific transforma- tion guided by a predefined set of compiler analysis and hand-crafted heuristics (Lattner & Adve, 2004). To pro- vide flexibility, compilers expose numerous configuration options that allow users to enable or disable specific opti- mizations or adjust heuristic parameters (Muchnick, 1998). However, interactions among optimization passes are often complex and difficult to predict (Kulkarni et al., 2006; Pal- lister et al., 2015), making it challenging to reason about or control global optimization strategies for a given program. Autotuning for Compiler Optimization. Building on the pass-by-pass optimization infrastructure, a line of work (Liang et al., 2023; Ansel et al., 2014; Chen et al., 2021; Zhu et al., 2024; Park et al., 2022; Pan et al., 2025) has explored autotuning approaches that search over com- piler options, optimization flags, or pass configurations to improve performance. While these methods can yield per- formance gains, it suffers from several inherent limitations. First, the search process is time-consuming, as it requires re- peated compilation (and, for runtime performance–oriented objectives, execution) under many configurations. Second, optimization options are coarse-grained: disabling, enabling, or reordering a pass affects all occurrences of that transfor- mation across the entire program. For example, if loop- invariant code motion is disabled at the option level to avoid harming a particular loop (as in Fig. 1(a)), other loops where LICM would be beneficial are also affected. LLMs for Compiler and Code Optimization. Recent work has begun to explore using LLMs for compiler con- struction and program optimization. Some approaches focus on enhancing compiler backend development effi- ciency (Zhong et al., 2024; 2025b;a), while others target source-level program rewriting for vectorization (Taneja et al., 2025). More closely related to our work are efforts that apply LLMs directly to IR-level optimization (Cummins et al., 2025; Yang et al., 2025), formulating optimization as an end-to-end generation task. While these methods by- pass the traditional pass-by-pass pipeline, they typically rely on black-box generation without explicit representations of optimization intent. In contrast, our work models optimiza- tion intent as an explicit intermediate step and integrates LLM-based reasoning with compiler knowledge to enable globally coordinated IR optimization. 3. Proposed Method: INTOPT To explicitly model and reason about optimization intent dur- ing compiler optimization, we propose INTOPT, an intent- driven IR optimization framework. As illustrated in Fig. 2, INTOPT contains three stages: intent formulation (Sec. 3.1), intent refinement (Sec. 3.2), and intent realization (Sec. 3.3). This structure decouples high-level optimization intent from low-level analysis and transformations, allowing INTOPT to make globally coordinated IR optimization. 3.1. Intent Formulation The intent formulation stage generates an initial optimiza- tion strategyS, which serves as a structured instantiation of the optimization intent, for a given input IR program P : S =F θ (P) whereF θ denotes an optimization-specialized LLM parame- terized byθ, fine-tuned on compiler optimization behaviors. The strategySis represented as an ordered sequence of transformation actions⟨a 1 ,a 2 ,...,a n ⟩, where each action 3 Submission and Formatting Instructions for ICML 2026 a i specifies in natural language which transformation to ap- ply to which program region (e.g., “Vectorize lineL 3 with <2 x double>”). Representing actions in natural language avoids prematurely constraining the optimization action space, allowing the model to reason over a richer and more flexible space of optimization strategies. Despite this flexibility, the problem remains tractable: while the space of semantically equiva- lent IR programs is vast, the set of transformation actions exposed by a modern compiler is finite and curated by com- piler developers. This bounded action set makes intent formulation amenable to data-driven learning from a mod- estly sized dataset. Consequently, to fine-tune the intent formulation modelF θ , we construct a dataset by distilling optimization intents from compiler behaviors. Dataset Construction. As shown in Fig. 2(a), we first col- lect a diverse set of IR programs from IR-OptSet (Yang et al., 2025), an IR-oriented dataset designed to trigger rep- resentative optimization transformations encountered in real compiler optimization scenarios. We compile the collected programs using LLVM 19.1.0 (LLVM, 2026a) with the-O3 flag to obtain paired unoptimized and optimized IR pro- grams(P unopt ,P opt ), where-O3enables a broad range of optimization passes. We then distill optimization intent from the observed end-to-end optimization behaviorP unopt toP opt by using GPT-5 (OpenAI, 2025) to infer the underly- ing optimization strategySfor each IR pair. The resulting triples – unoptimized IRP unopt , optimized IRP opt , and inferred strategy S – constitute the training datasetD train . Model Training.We fine-tune LLM Compiler FTD 13B (Cummins et al., 2025), an LLM for IR optimization, on D train to obtain the optimization-specialized LLMF θ . The training objective is to minimize the negative log-likelihood of generating the ground-truth optimization strategyScon- ditioned on the unoptimized IR program P unopt : L(θ) =−E (P unopt ,S)∼D train logp θ (S | P unopt ) The choice of a 13B-parameter model is deliberate: intent formulation is primarily pattern recognition over program structures and compiler optimization behaviors, which does not require the extensive reasoning capabilities needed for subsequent refinement and realization stages. This design balances effectiveness with computational efficiency. 3.2. Intent Refinement The intent formulation stage produces an initial optimiza- tion strategy that specifies which transformations to apply and in what order. Although this strategy captures high- level optimization intent learned from compiler behaviors, it is inferred in a data-driven manner and may miss key constraints from program semantics or target-specific re- quirements. The intent refinement stage therefore grounds the initial strategy in concrete compiler analysis and revises it when needed, ensuring that each proposed transformation is applicable and well-informed. A key challenge of intent refinement is identifying which compiler analysis is necessary to refine the given strategy S. Since different transformations rely on different types of analysis, retrieving all available analysis is both inefficient and unnecessary. To address this challenge, we design an analysis-aware re- trieval mechanism that explicitly captures the relationship between transform passes and their required analysis. By constructing a structured compiler knowledge base and us- ing it to retrieve only the analysis relevant to each trans- formation action inS, the refinement process concentrates on the most informative analysis signals while avoiding unnecessary overhead. Compiler Knowledge Base Construction. We construct a structured knowledge baseKthat catalogs compiler opti- mization passes (i.e., transform passes) and their analysis dependencies. Each entry k ∈K is represented as: k = (ID,Desc,Deps), whereIDuniquely identifies a transform pass (correspond- ing to its pass class name, e.g.,LoopVectorizePass), Descprovides a natural-language description of the pass’s functionality and optimization objectives, andDepsdenotes the set of compiler analysis required by the pass. We buildKthrough an automatic extraction pro- cess from the LLVM compiler infrastructure.First, we parsellvm/lib/Passes/PassRegistry.def, which enumerates all transform passes, to obtain the set of pass identifiersID. For each pass, we then extract its functional description from the official LLVM pass docu- mentation 1 to populate the corresponding Desc field. To extract the analysis dependenciesDeps, we exploit a key design principle of LLVM: each transform pass must explicitly declare analysis passes it relies on by invok- ingAnalysisManager::getResultwithin itsrun method. Accordingly, LLVM provides a collection of analysis passes, each responsible for extracting specific optimization-related information from the IR programs to guide transformation decisions. This explicit dependency mechanism allows us to systematically trace which analy- sis passes are required by each transform pass, yielding a reliable and complete specification of its analysis require- ments. For example,LoopVectorizePassrequests loop-structure and target-specific analysis as follows: Preservedanalysis LoopVectorizePass::run(..., AnalysisManager &AM) ... 1 https://llvm.org/docs/Passes.html 4 Submission and Formatting Instructions for ICML 2026 auto &LI = AM.getResult<LoopAnalysis>(F); auto &TLI = AM.getResult<TargetLibraryAnalysis>(F); ... Therefore, we obtain theDepsfield by locating each pass’srunimplementation underllvm/lib/ Transforms and statically parsing all invocations of AnalysisManager::getResult.As shown in Fig. 2(b), the dependency set forLoopVectorizePass isLoopAnalysis, TargetLibraryAnalysis. Retrieve Analysis Results. With the constructed compiler knowledge baseK, we retrieve the concrete compiler trans- form passes and their dependent analysis passes correspond- ing to each transformation actiona i in the initial optimiza- tion strategyS. Specifically, for each actiona i , we treat the natural-language description ofa i as a query and match it against the document corpusDesc(k) k∈K . Both the query and documents are represented using TF-IDF (Zhang et al., 2011) with 1–3 gram tokenization, and the top-m matching passes are selected based on cosine similarity. sim(a i ,k) = cos(TF-IDF(a i ), TF-IDF(Desc(k))) k (j) i m j=1 = arg top-m k∈K sim(a i ,k) Such design balances efficiency and coverage: top-m re- trieval captures cases where multiple passes address similar goals (e.g.,EarlyCSEPass,DCEPass, andGVNPass all perform redundancy elimination) while avoiding the com- putational overhead of indiscriminate analysis execution. Once the passesk (j) i m j=1 are identified, we retrieve their required analysis passesDeps(k (j) i )from the knowledge base and invoke the LLVM compiler to generate the corre- sponding analysis results on the current IR program P : R S = [ a i ∈S m [ j=1 LLVMGenerate(Deps(k (j) i ),P) Theanalysisresultsareobtainedthrough LLVM’s analysis inspection interfaces (e.g.,opt -p=print<analysis>), which generate analysis infor- mation in textual form. This information corresponds to the same analysis results that transform passes query during the compiler optimization process to ensure correctness and performance. As a result, they provide reliable information for downstream intent refinement and intent realization. Refinement. Given the initial optimization strategySand the retrieved analysis resultsR S , the refinement stage pro- duces a refined strategy ˆ S: ˆ S =G(P,S,R S ) whereGdenotes the LLM (GPT-5) that performs intent refinement by reasoning over the program, initial strategy, and compiler analysis information. The prompt template used during refinement is provided in Appendix B. This refinement process validates and enhances the initial strategy in Section 3.1 by grounding it in compiler analy- sis information: it filters infeasible transformations based on program constraints, while leveraging both analysis in- formation and the LLM’s pretraining knowledge to refine the transformations in ways that may exceed conventional compiler heuristics. The resulting strategy ˆ Sis constraint- aware and analytically informed, providing a reliable bridge between intent formulation and concrete intent realization. 3.3. Intent Realization The intent realization stage finally applies the strategy ˆ S on the unoptimized IR programPto generate the optimized IR program ˆ P : ˆ P =G(P, ˆ S,R S ) whereGdenotes the same LM (GPT-5) used in refinement. This stage synthesizes the optimized program by applying the transformation actions specified in ˆ Swhile respecting the constraints encoded in the analysis resultsR S . The prompt template is provided in Appendix B. Through this three-stage pipeline – formulation, refinement, and realization – INTOPT transforms high-level optimiza- tion intent into concrete, well-informed IR transformations. Leveraging GPT-5 for intent refinement and realization al- low INTOPT to explore optimization strategies beyond those typically produced by traditional fixed-pass compilers. 4. Experiments This section explores the following research questions: •RQ.1 Can INTOPT outperform existing end-to-end LLM- based IR optimization approaches? (Sec. 4.2) •RQ.2 How does INTOPT compare against the traditional compiler in terms of performance? Does the explicit optimization intent lead to performance gains beyond the pass-by-pass paradigm? (Sec. 4.3 & Sec. 4.4) •RQ.3 How does each component of INTOPT contribute to its overall results? (Sec. 4.5) 4.1. Experimental Setup 4.1.1. DATASET We construct all datasets from IR-OptSet (Yang et al., 2025), an IR-oriented dataset designed to trigger representative optimization transformations encountered in real compiler optimization scenarios, and each IR sample (unoptimized IR plus optimized IR) is capped at 5,000 tokens. We randomly sample 4,000 programs to form the training setINT train 5 Submission and Formatting Instructions for ICML 2026 Table 1. Comparison of correctness and performance of six LLM-based IR optimization methods. Correctness is evaluated using Alive2 combined with differential testing, while performance is measured as speedup over the input unoptimized IR. Method CorrectnessPerformance Alive2Alive2+Diff. Test.Avg. Speedup Speedup > 1.1× Speedup > 1.5× Speedup > 2.0× GPT-573.0% (146)83.5% (167)1.057×26.0% (52)10.5% (21)6.5% (13) Claude Haiku 4.554.0% (108)61.0% (122) 0.721×15.5% (31)5.0% (10)2.5% (5) DeepSeek-V3.251.0% (102)59.0% (118)0.719×14.5% (29)6.5% (13)3.5% (7) LLM Compiler FTD 7B57.0% (114)60.5% (121) 0.702×13.0% (26)6.0% (12)2.5% (5) LLM Compiler FTD 13B 61.5% (123)64.5% (129)0.757×12.0% (24)4.0% (8)2.5% (5) INTOPT71.0% (142)90.5% (181)2.660×37.5% (75)17.5% (35)10.0% (20) and 500 programs to form the validation setINT val . For evaluation, we construct a separate test setINT test of 200 IR samples through a multi-stage filtering process. First, we retain programs for which Alive2 (Lopes et al., 2021) can verify semantic equivalence between the unoptimized IR and LLVM-O3. Second, we exclude programs unsuitable for differential testing (McKeeman, 1998), such as those with custom external functions, externally defined global variables, or non-deterministic behavior. This ensures that when LLM-based optimizers produce transformations be- yond Alive2’s verification capability, differential testing can be reliably used for correctness validation. 4.1.2. BASELINES We include two categories of baselines for comparison: End-to-end LLM-based IR optimizers. We consider both general-purpose and specialized LLM-based optimizers that directly map unoptimized IR to optimized IR. Specifically, we evaluate three representative general-purpose LLMs with strong capabilities on code-related tasks: GPT-5 (OpenAI, 2025), Claude Haiku 4.5 (Anthropic, 2025), and DeepSeek- V3.2 (DeepSeek-AI et al., 2025). All models are prompted using the template shown in Appendix C. We also compare against LLM Compiler (Cummins et al., 2025), a state-of- the-art specialized end-to-end IR optimizer, evaluating both the 7B and 13B parameter variants (LLM Compiler FTD 7B and LLM Compiler FTD 13B). To ensure a fair comparison, both LLM Compiler variants are fine-tuned onINT train with INT val following Appendix E. Compiler baseline. We include LLVM 19.1.0 (LLVM, 2026a) with the-O3optimization level as a compiler- level reference.-O3aggressively optimizes for execution speed (LLVM, 2026c) and represents a highly tuned IR optimization strategy. 4.1.3. IMPLEMENTATION DETAILS For the intent formulation stage of INTOPT, we obtain the optimization-specialized LLMF θ in INTOPT, using the INT train withINT val , following the procedure described in Sec. 3.1. During the analysis results retrieval stage, we select the top-3 matching optimization passes and collect their corresponding LLVM analysis results, which are used to support the intent refinement stage. 4.1.4. EVALUATION METRICS Correctness Verification. We employ a two-stage veri- fication process to validate the Correctness of optimized IR programs. We first apply Alive2 to perform strict for- mal semantic equivalence checking between the optimized and unoptimized IR. Since Alive2 may time out on verify- ing programs with complex control flow or memory behav- iors (Lopes et al., 2021), we additionally apply differential testing when formal verification is infeasible. Specifically, we use LibFuzzer (LLVM, 2026b) to generate diverse test inputs and verify that optimized and unoptimized programs produce identical outputs across different execution paths. Details are provided in Appendix F. Performance Evaluation. We measure performance using the same inputs generated by LibFuzzer during correctness verification, reflecting execution behaviors across diverse control flow paths. Each program is executed for 10,000 iterations to obtain stable timing measurements and mitigate measurement noise. We report Performance as speedup ratio:Speedup = RunTime(unopt)/RunTime(opt). When an LLM-based optimizer generates incorrect IR, we assign a speedup of 0. More details are in Appendix G. 4.2. Improvement over LLM-based IR Optimizers We first compare INTOPT with end-to-end LLM-based IR optimizers on the 200-sample benchmarkINT test . As shown in Table 1, INTOPT achieves the strongest overall results across all baselines in both correctness and performance. Correctness.Under Alive2-only verification, GPT-5 achieves the highest correctness rate among baselines (73.0%), while INTOPT attains a comparable rate of 71.0%. However, this metric is inherently limited by Alive2’s verifi- cation capability: even complex optimizations produced by LLVM-O3cannot always be verified (Lopes et al., 2021). When differential testing is incorporated, INTOPT achieves a verified correctness rate of 90.5%, surpassing all other baselines by 7.0%-31.5%. These results highlight INTOPT ’s advantage in reducing semantic errors over end-to-end LLM-based IR optimization methods. Performance. INTOPT achieves an average speedup of 2.660×over the unoptimized IR, significantly outperform- ing all end-to-end LLM-based baselines.The strongest base- 6 Submission and Formatting Instructions for ICML 2026 Better (62)Equal (95)Worse (43) 287.72 0.0 1.5 3.0 4.5 6.0 S p e e d u p Better (118)Equal (62)Worse (20) 0.0 1.5 3.0 4.5 6.0 S p e e d u p 287.72 IR Samples (200) IR Samples (200) IntOpt Avg. 2.660 GPT-5 Avg. 1.057 LLM Compiler FTD 13B Avg. 0.757 (a) IntOpt vs. GPT-5 (b) IntOpt vs. LLM Compiler FTD 13B [0.50,0.90) [0.90,0.98) Wrong 27 12 19 Speedup Better Worse Equal 37 58 105 S p e e d u p v s . L L V M - O 3 1.0 1.5 2.0 13 samples 19 samples > 1.10x> 1.02x IR Samples (37) 5 samples > 1.50x 272.60 Figure 3. Per-program speedup comparison between INTOPT and representative end-to-end LLM-based IR optimizers. Speedup differences within±2% are considered equal to account for runtime variability. Better (62)Equal (95)Worse (43) 287.72 0.0 1.5 3.0 4.5 6.0 S p e e d u p Better (118)Equal (62)Worse (20) 0.0 1.5 3.0 4.5 6.0 S p e e d u p 287.72 IR Samples (200) IR Samples (200) IntOpt Avg. 2.660 GPT-5 Avg. 1.057 LLM Compiler FTD 13B Avg. 0.757 (a) IntOpt vs. GPT-5 (b) IntOpt vs. LLM Compiler FTD 13B [0.50,0.90) [0.90,0.98) Wrong 27 12 19 Speedup Better Worse Equal 37 58 105 S p e e d u p v s . L L V M - O 3 1.0 1.5 2.0 13 samples 19 samples > 1.10x> 1.02x IR Samples (37) 5 samples > 1.50x 272.60 Figure 4. Performance comparison between INTOPT and LLVM-O3. Speedup is defined asRunTime(LLVM -O3)/RunTime(opt), with[0.98, 1.02]treated as equal. INTOPT matches LLVM-O3on 105 programs and outperforms it on 37 (max272.60×); among 58 underperforming cases, most are slight slowdowns (27 in [0.90, 0.98]), and 19 are incorrect. line, GPT-5, attains an average speedup of only 1.057×, resulting in a 1.603×performance gap. Beyond average performance, INTOPT also consistently dominates across all speedup thresholds, indicating that its performance gains are broadly distributed across the benchmark. To better understand these improvements, we further com- pare INTOPT against the two strongest baselines, GPT-5 and LLM Compiler FTD 13B, on a per-program basis, as shown in Fig. 3. Against GPT-5, INTOPT achieves higher speedups on 62 programs, while the advantage is more pronounced against LLM Compiler FTD 13B, where INTOPT outper- forms it on 118 programs. Notably, when compared to the unoptimized IR, INTOPT attains a maximum speedup of up to287.72×on a single program. These results suggest that INTOPT is more effective at discovering and realizing aggressive yet profitable optimization opportunities. Answer to RQ.1:By decoupling optimization intent formu- lation from concrete transformation generation, INTOPT reduces semantic errors and is more effective at discovering profitable optimization opportunities than existing end-to- end LLM-based IR optimization approaches. 4.3. Improvement over Traditional Compiler We further compare INTOPT’s performance against LLVM -O3, a highly optimized and widely adopted compiler opti- mization level. Fig. 4 shows the comparison results. INTOPT achieves performance comparable to LLVM-O3 on 105 programs and outperforms it on 37 programs. Among these improved cases, the per-program speedup distribution reveals a spectrum of performance gains: 5 programs exhibit substantial improvements with speedups greater than1.5×, while 13 programs achieve clear improve- ments exceeding1.1×. Notably, the program that achieves the highest speedup in Fig. 3 also attains the highest perfor- mance improvement over LLVM-O3, with a speedup of up to272.60×. We analyze this case in detail in Sec. 4.4, illus- trating how INTOPT can uncover optimization opportunities that go beyond the capabilities of the traditional compiler. 4.4. Case Analysis To provide deeper insights into the intent-driven optimiza- tion mechanism, we present two representative cases that illustrate how INTOPT explores optimization opportunities beyond the traditional pass-by-pass compiler paradigm. Due to space constraints, we present pseudo-code representations of the IR; the full code listings are provided in Appendix H. As shown in Fig. 5, traditional compilers primarily opti- mize programs by matching pre-defined patterns in passes designed by compiler developers and applying transforma- tions (e.g., eliminating stack-based load/store operations). In contrast, INTOPT performs intent-guided optimization that enables coordinated, semantic-aware transformations. InchocolateFeast, INTOPT identifies an algorithmic shortcut during intent refinement that reduces the time com- plexity of an iterative computation toO(1)and guides the subsequent optimization, achieving a287.72×speedup. Inreversebits, INTOPT achieves a1.97×speedup by coordinating multiple transformations. After recog- nizing the high-level semantics of the loop as bit rever- sal, INTOPT replaces the original computation with the 7 Submission and Formatting Instructions for ICML 2026 chocolateFeast(N, C, M): entry: # initial chocolates (and wrappers) init = N / C # not enough wrappers to redeem if (init < M) return init loop: total = phi[init(entry), total'(loop)] wrap = phi[init(entry), wrap'(loop)] total'= total + 1 wrap' = wrap - M + 1 # not enough wrappers to redeem if (wrap' >= M) goto loop return total' Program Description: Computes the total chocolates obtainable when spending N dollars, where each chocolate costs C dollars and produces one wrapper, and M wrappers can be redeemed for one additional chocolate. All values are first stored on the stack ('st') and then loaded for each operation. LLVM -O3 Eliminate all stack-based load/store operations; Remove redundant ' N/C ' computation. chocolateFeast(N, C, M): entry: init = N / C if (M > 1 && init > 0) extra = (init - 1) / (M - 1) return init + Extra if (init < M) return init loop: total = phi[init(entry), total'(loop)] wrap = phi[init(entry), wrap'(loop)] total'= total + 1 wrap' = wrap - M + 1 if (wrap' >= M) goto loop return total' IntOpt Speedup: 1.06xSpeedup: 287.72x chocolateFeast(N, C, M): entry: # stack allocation st[3] = N, st[4] = C, st[5] = M st[6] = st[3] / st[4] st[7] = st[3] / st[4] loop: # not enough wrappers to redeem if (st[7] < st[5]) goto end st[7] = st[7] - st[5] # spend M wrappers st[6] = st[6] + 1 # gain one chocolate # gain one wrapper from the new chocolate st[7] = st[7] + 1 goto loop end: return st[6] # total chocolates Input IR # initial chocolates Time Complexity: O(1) Refined Strategy When M > 1 and the init > 0, the number of exchanges is ' (init - 1) / (M - 1) '. Return 'init + (init - 1) / (M - 1) ' without entering the loop. Program Description: Reverses the bit of a 32-bit integer N by iteratively extracting the lowest bit and building the result from left to right. reverse_bits(N): entry: st[1] = N, st[2] = 0 # stack allocation loop: if (st[1] == 0) goto exit st[2] = st[2] << 1 # shift result left st[3] = st[1] & 1 # extract lowest bit st[2] = st[2] | st[3] # append bit to result st[1] = st[1] >> 1 # shift input right goto loop exit: return st[2] # reversed bits Input IR reverse_bits(N): entry: if (N == 0) return 0 loop: input = phi[N(entry), input'(loop)] result = phi[0(entry), result'(loop)] result' = (result << 1) | (input & 1) input' = input >> 1 # stop when input<2 (input' must be 0) if (input < 2) return result' goto loop reverse_bits(N): entry: if (N == 0) return 0 fast: # hardware bit-reverse intrinsic brev = call @llvm.bitreverse.i32(N) # find the leading zero clz = call @llvm.ctlz.i32(N, false) # remove leading zeros from reversed res = brev >> clz return res Replace the loop with llvm intrinsic that backend can map to hardware: llvm.bitreverse.i32 to reverse all 32 bits, and llvm.ctlz.i32 to compute the number of leading zeros. Eliminate stack-based load/store operations; Add an early-exit condition 'input < 2' to avoid redundant iterations. All values are first stored on the stack ('st') and then loaded for each operation. Effective Utilization of Hardware Instructions LLVM -O3 Speedup: 1.13x IntOpt Speedup: 1.97x # initial wrappers Refined Strategy Figure 5. Case study illustrating how INTOPT explores optimization opportunities beyond the traditional pass-by-pass compiler paradigm. Table 2. Ablation study of INTOPT ’s design. Impact of intent refinement and compiler analysis on correctness and performance, where performance is measured as speedup over the input unoptimized IR. Method CorrectnessPerformance Alive2Alive2+Diff. Test.Avg. Speedup Speedup > 1.1× Speedup > 1.5× Speedup > 2.0× INTOPT71.0% (142)90.5% (181)2.660×37.5% (75)17.5% (35)10.0% (20) w/o Intent Refinement 71.5% (143)87.0% (174) 1.122×30.0% (60)15.0% (30)7.5% (15) w/o Analysis65.0% (130)77.0% (154)2.415×29.0% (58)13.0% (26)6.5% (13) llvm.bitreverseintrinsic, and further applies an aux- iliary transformation usingllvm.ctlzwith shift-based operations to model the original loop’s exit condition. These optimizations are difficult for existing compilers to realize, as they require semantic reasoning beyond what local pat- tern matching in a fixed pass-by-pass pipeline can capture. Answer to RQ.2:Explicit optimization intent enables IN- TOPT to realize optimizations that go beyond the capabili- ties of traditional pass-by-pass compilers. 4.5. Effectiveness of INTOPT ’s Design The intent formulation stage is a necessary first stage in this pipeline, while intent realization serves as the final stage that generates optimized IR; neither can be bypassed. Ac- cordingly, our ablation study focuses on the contribution of the intent refinement stage and the impact of compiler analysis on INTOPT. As shown in Table 2, removing intent refinement slightly improves Alive2-only correctness but leads to a noticeable degradation in both verified correctness and performance, reducing average speedup from2.660×to 1.122×. Removing compiler analysis from both refinement and realization (w/o Analysis) further reduces verified cor- rectness to 77.0%, as refinement and realization decisions are made without sufficient semantic constraints. Despite this, performance remains relatively high (2.415×on aver- age). This behavior can be attributed to the fact that, starting from compiler-derived optimization intents produced dur- ing intent formulation, the LLM can occasionally identify highly aggressive transformations, including the case shown in Fig. 3 that achieves a speedup of 287.72×. Answer to RQ.3:Both intent refinement and compiler anal- ysis are both critical to INTOPT, enabling effective optimiza- tion discovery and reliable realization. 5. Conclusion This paper introduces INTOPT, the first intent-driven IR optimization framework. By decoupling high-level opti- mization intent from low-level analysis and transformation, INTOPT addresses a critical yet underexplored dimension of IR optimization. Our experimental results show that INTOPT delivers substantial improvements over both end- to-end LLM-based optimizers and traditional compiler opti- mizations, demonstrating that making optimization intent explicit is crucial for achieving globally coordinated, seman- tically sound, and high-performance IR optimization. 8 Submission and Formatting Instructions for ICML 2026 Impact Statement This work explores the use of LLMs to assist IR optimiza- tion in compilers, a domain where correctness, reliability, and performance are critical. By explicitly modeling opti- mization intent and separating it from low-level transforma- tions, the proposed framework enhances the interpretability and inspectability of LLM-assisted compiler optimization, enabling developers to better understand and verify the opti- mization strategies produced by these systems. We believe that intent-driven optimization provides a promising foun- dation for future research at the intersection of compilers and machine learning, fostering more trustworthy and ex- plainable AI-assisted program optimization. References Aho, A. V., Lam, M. S., Sethi, R., and Ullman, J. D. Com- pilers: Principles, Techniques, and Tools (2nd Edition). Addison-Wesley Longman Publishing Co., Inc., USA, 2006. ISBN 0321486811. Ansel, J., Kamil, S., Veeramachaneni, K., Ragan-Kelley, J., Bosboom, J., O’Reilly, U.-M., and Amarasinghe, S. Opentuner: An extensible framework for program auto- tuning. In 2014 23rd International Conference on Paral- lel Architecture and Compilation Techniques (PACT), p. 303–315, 2014. doi: 10.1145/2628071.2628092. Anthropic.Claude Haiku 4.5.https://w. anthropic.com/claude/haiku, 2025. Bezanson, J., Edelman, A., Karpinski, S., and Shah, V. B. Julia: A fresh approach to numerical computing. SIAM Rev., 59(1):65–98, January 2017. ISSN 0036-1445. doi: 10.1137/141000671. URLhttps://doi.org/10. 1137/141000671. Chen, J., Xu, N., Chen, P., and Zhang, H. Efficient compiler autotuning via bayesian optimization. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), p. 1198–1209, 2021. doi: 10.1109/ICSE43902. 2021.00110. Chen, T., Moreau, T., Jiang, Z., Zheng, L., Yan, E., Cowan, M., Shen, H., Wang, L., Hu, Y., Ceze, L., Guestrin, C., and Krishnamurthy, A. Tvm: an automated end-to-end optimizing compiler for deep learning. In Proceedings of the 13th USENIX Conference on Operating Systems De- sign and Implementation, OSDI’18, p. 579–594, USA, 2018. USENIX Association. ISBN 9781931971478. Cummins, C., Seeker, V., Grubisic, D., Roziere, B., Gehring, J., Synnaeve, G., and Leather, H. Llm compiler: Founda- tion language models for compiler optimization. In Pro- ceedings of the 34th ACM SIGPLAN International Con- ference on Compiler Construction, p. 141–153, 2025. Daya, G., Dejian, Y., and et al., Z. H. DeepSeek-R1 incen- tivizes reasoning in LLMs through reinforcement learn- ing. Nature, 645(8081):633–638, September 2025. doi: https://doi.org/10.1038/s41586-025-09422-z. DeepSeek-AI, Liu, A., and et al., A. M. Deepseek-v3.2: Pushing the frontier of open large language models, 2025. URL https://arxiv.org/abs/2512.02556. GCC. Gnu compiler collection.https://gcc.gnu. org, 2026. Kulkarni, P., Whalley, D., Tyson, G., and Davidson, J. Exhaustive optimization phase order space exploration. In International Symposium on Code Generation and Optimization (CGO’06), p. 13 p.–318, 2006. doi: 10.1109/CGO.2006.15. Lattner, C. and Adve, V. Llvm: a compilation frame- work for lifelong program analysis & transformation. In International Symposium on Code Generation and Optimization, 2004. CGO 2004., p. 75–86, 2004. doi: 10.1109/CGO.2004.1281665. Lattner, C., Amini, M., Bondhugula, U., Cohen, A., Davis, A., Pienaar, J., Riddle, R., Shpeisman, T., Vasilache, N., and Zinenko, O. Mlir: Scaling compiler infras- tructure for domain specific computation.In 2021 IEEE/ACM International Symposium on Code Gener- ation and Optimization (CGO), p. 2–14, 2021. doi: 10.1109/CGO51591.2021.9370308. Liang, Y., Stone, K., Shameli, A., Cummins, C., Elhoushi, M., Guo, J., Steiner, B., Yang, X., Xie, P., Leather, H., and Tian, Y. Learning compiler pass orders using core- set and normalized value prediction. In Proceedings of the 40th International Conference on Machine Learning, ICML’23. JMLR.org, 2023. LLVM. The llvm compiler infrastructure project.http: //llvm.org/, 2026a. LLVM. libFuzzer – a library for coverage-guided fuzz testing., 2026b. URLhttps://llvm.org/docs/ LibFuzzer.html. LLVM.Optimization Level, 2026c.URLhttps: //llvm.org/docs/doxygen/classllvm_1_ 1OptimizationLevel.html. Lopes, N. P., Lee, J., Hur, C.-K., Liu, Z., and Regehr, J.Alive2: bounded translation validation for llvm. In Proceedings of the 42nd ACM SIGPLAN Interna- tional Conference on Programming Language Design and Implementation, PLDI 2021, p. 65–79, New York, NY, USA, 2021. Association for Computing Machinery.ISBN 9781450383912.doi: 10.1145/ 3453483.3454030.URLhttps://doi.org/10. 1145/3453483.3454030. 9 Submission and Formatting Instructions for ICML 2026 McKeeman, W. M. Differential testing for software. Digit. Tech. J., 10:100–107, 1998.URLhttps://api. semanticscholar.org/CorpusID:14018070. Moses, W. S., Ivanov, I. R., Domke, J., Endo, T., Do- erfert, J., and Zinenko, O. High-performance gpu-to- cpu transpilation and optimization via high-level paral- lel constructs. In Proceedings of the 28th ACM SIG- PLAN Annual Symposium on Principles and Practice of Parallel Programming, PPoPP ’23, p. 119–134, New York, NY, USA, 2023. Association for Comput- ing Machinery. ISBN 9798400700156. doi: 10.1145/ 3572848.3577475.URLhttps://doi.org/10. 1145/3572848.3577475. Muchnick, S. S. Advanced compiler design and implemen- tation. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1998. ISBN 1558603204. OpenAI. Introducing GPT-5.https://openai.com/ index/introducing-gpt-5/, 2025. Pallister, J., Hollis, S. J., and Bennett, J. Identifying com- piler options to minimize energy consumption for em- bedded platforms. The Computer Journal, 58(1):95–109, 2015. doi: 10.1093/comjnl/bxt129. Pan, H., Wei, Y., Xing, M., Wu, Y., and Zhao, C. To- wards efficient compiler auto-tuning: Leveraging syn- ergistic search spaces.In Proceedings of the 23rd ACM/IEEE International Symposium on Code Gener- ation and Optimization, CGO ’25, p. 614–627, New York, NY, USA, 2025. Association for Computing Machinery.ISBN 9798400712753.doi: 10.1145/ 3696443.3708961.URLhttps://doi.org/10. 1145/3696443.3708961. Park, S., Latifi, S., Park, Y., Behroozi, A., Jeon, B., and Mahlke, S. Srtuner: Effective compiler optimization cus- tomization by exposing synergistic relations. In 2022 IEEE/ACM International Symposium on Code Genera- tion and Optimization (CGO), p. 118–130, 2022. doi: 10.1109/CGO53902.2022.9741263. Sabne, A. Xla : Compiling machine learning for peak performance, 2020. Stanier, J. and Watson, D. Intermediate representations in imperative compilers: A survey. ACM Comput. Surv., 45(3), July 2013. ISSN 0360-0300. doi: 10. 1145/2480741.2480743. URLhttps://doi.org/ 10.1145/2480741.2480743. Taneja, J., Laird, A., Yan, C., Musuvathi, M., and Lahiri, S. K. Llm-vectorizer: Llm-based verified loop vector- izer. In Proceedings of the 23rd ACM/IEEE International Symposium on Code Generation and Optimization, CGO ’25, p. 137–149, New York, NY, USA, 2025. Associa- tion for Computing Machinery. ISBN 9798400712753. doi: 10.1145/3696443.3708929. URLhttps://doi. org/10.1145/3696443.3708929. Yang, Z., Qiu, L., Lyu, Fang Zhong, M., Chai, Z., Zhou, H., Cui, H., and Feng, X. Ir-optset: An optimization-sensitive dataset for advancing llm-based ir optimizer. Advances in Neural Information Processing Systems, 38, 2025. Zhang, W., Yoshida, T., and Tang, X.A com- parative study of tf*idf, lsi and multi-words for text classification.Expert Systems with Appli- cations, 38(3):2758–2765, 2011.ISSN 0957- 4174.doi:https://doi.org/10.1016/j.eswa.2010.08. 066. URLhttps://w.sciencedirect.com/ science/article/pii/S0957417410008626. Zhong, M., Lyu, F., Wang, L., Geng, H., Qiu, L., Cui, H., and Feng, X. Comback: A versatile dataset for enhanc- ing compiler backend development efficiency. Advances in Neural Information Processing Systems, 37:112310– 112328, 2024. Zhong, M., Lv, F., Wang, L., Qiu, L., Wang, Y., Liu, Y., Cui, H., Feng, X., and Xue, J. VEGA: Automatically Generat- ing Compiler Backends using a Pre-trained Transformer Model. In Proceedings of the 23rd ACM/IEEE Interna- tional Symposium on Code Generation and Optimization, CGO ’25, p. 90–106, New York, NY, USA, 2025a. Asso- ciation for Computing Machinery. ISBN 9798400712753. doi: 10.1145/3696443.3708931. URLhttps://doi. org/10.1145/3696443.3708931. Zhong, M., Sun, X., Lv, F., Wang, L., Geng, H., Qiu, L., Cui, H., and Feng, X. BePilot: An AI Programming Assistant for Compiler Backend Development. ACM Trans. Softw. Eng. Methodol., 2025b. ISSN 1049-331X. doi: 10.1145/3764585. URLhttps://doi.org/10. 1145/3764585. Just Accepted. Zhu, M., Hao, D., and Chen, J. Compiler autotuning through multiple-phase learning. ACM Trans. Softw. Eng. Methodol., 33(4), April 2024. ISSN 1049-331X. doi: 10.1145/3640330. URLhttps://doi.org/10. 1145/3640330. ̈ Ozen, G., Atzeni, S., Wolfe, M., Southwell, A., and Klimow- icz, G. Openmp gpu offload in flang and llvm. In 2018 IEEE/ACM 5th Workshop on the LLVM Compiler In- frastructure in HPC (LLVM-HPC), p. 1–9, 2018. doi: 10.1109/LLVM-HPC.2018.8639434. 10 Submission and Formatting Instructions for ICML 2026 A. Example of Compiler Analysis Information In this section, we provide a detailed example of how compiler analysis information guides the optimization process for an input IR program, as shown in Fig. 6. It contains two types of branches: (1) unconditional branch (e.g.,br label %B1), which is a type of branch directly jumps to another block without any conditions; (2) conditional branch (br i1 %16, label %B2, label %B3), which is a type of branch performs a jump based on a condition. define dso_local i32 @chocolateFeast(i32 noundef %0, i32 noundef %1, i32 noundef %2) B0: %3 = alloca i32, align 4 %4 = alloca i32, align 4 %5 = alloca i32, align 4 %6 = alloca i32, align 4 %7 = alloca i32, align 4 store i32 %0, ptr %3, align 4, !tbaa !5 store i32 %1, ptr %4, align 4, !tbaa !5 store i32 %2, ptr %5, align 4, !tbaa !5 call void @llvm.lifetime.start.p0(i64 4, ptr %6) #2 %8 = load i32, ptr %3, align 4, !tbaa !5 %9 = load i32, ptr %4, align 4, !tbaa !5 %10 = sdiv i32 %8, %9 store i32 %10, ptr %6, align 4, !tbaa !5 call void @llvm.lifetime.start.p0(i64 4, ptr %7) #2 %11 = load i32, ptr %3, align 4, !tbaa !5 %12 = load i32, ptr %4, align 4, !tbaa !5 %13 = sdiv i32 %11, %12 store i32 %13, ptr %7, align 4, !tbaa !5 br label %B1 B1: %14 = load i32, ptr %5, align 4, !tbaa !5 %15 = load i32, ptr %7, align 4, !tbaa !5 %16 = icmp sle i32 %14, %15 br i1 %16, label %B2, label %B3 B2: %17 = load i32, ptr %7, align 4, !tbaa !5 %18 = load i32, ptr %5, align 4, !tbaa !5 %19 = sub nsw i32 %17, %18 store i32 %19, ptr %7, align 4, !tbaa !5 %20 = load i32, ptr %6, align 4, !tbaa !5 %21 = add nsw i32 %20, 1 store i32 %21, ptr %6, align 4, !tbaa !5 %22 = load i32, ptr %7, align 4, !tbaa !5 %23 = add nsw i32 %22, 1 store i32 %23, ptr %7, align 4, !tbaa !5 br label %B1, !llvm.loop !9 B3: %24 = load i32, ptr %6, align 4, !tbaa !5 call void @llvm.lifetime.end.p0(i64 4, ptr %7) #2 call void @llvm.lifetime.end.p0(i64 4, ptr %6) #2 ret i32 %24 Figure 6. Example of the input IR Below, we break down the key elements of the analysis and explain what each part means. A.1. Dominator Tree Analysis The Dominator Tree is a data structure used to identify the dominance relationships between basic blocks in a control flow graph (CFG) of the function. A blockBdominates another blockCif every path from the entry block toCmust go throughB. The Dominator Tree helps identify potential places for optimization by highlighting which blocks are crucial for 11 Submission and Formatting Instructions for ICML 2026 execution and which may be redundant or amenable to optimization. For the functionchocolateFeast, the dominator tree is shown as follows: DominatorTree for function: chocolateFeast =============================-------------------------------- Inorder Dominator Tree: DFSNumbers invalid: 0 slow queries. [1] %B0 [2] %B1 [3] %B2 [3] %B3 Roots: %B0 • %B0is at level 1, which indicates it is the entry block (starting point of the function). As the root of the dominator tree, %B0dominates all other blocks. It is the first block that will be executed when the function is called, and every other block must pass through it. • %B1 is at level 2, meaning it is one step deeper in the control flow compared to%B0. This block is dominated by%B0, and it is the first block executed after %B0. •Both%B2and%B3are at level 3, meaning they are two steps deeper in the control flow than%B0. These blocks are dominated by %B1, meaning they are only executed after %B1. A.2. Loop Analysis Loops are a key target for optimization, as they are often the source of performance bottlenecks. Loop analysis identifies the loops within the function and provides details on their structure, such as their depth and the basic blocks involved. In a loop structure, the loop header is the first block in the loop, where all edges from outside the loop converge. The loop latch is a node inside the loop with an edge pointing back to the loop header. The exit block is the block where control exits the loop, marking the termination point of the loop. For the function chocolateFeast, the loop analysis is shown as follows: Loop info for function ’chocolateFeast’: Loop at depth 1 containing: %B1<header><exiting>,%B2<latch> • The loop is at depth 1, meaning it’s a top-level loop in the function. • The loop involves %B1 as the loop header and the exit block, %B2 as the loop latch. B. Prompt Template for INTOPT B.1. Intent Formulation Prompt Template The intent formulation stage in INTOPT generates an initial optimization strategyS, which serves as a structured instantiation of the optimization intent for a given input IR programP. To train the fine-tuned LLM Compiler FTD 13B, we use the following template to guide it in producing an ordered sequence of natural language transformation actions: [INST]Given the following LLVM IR, propose key optimization transformation steps to outperform LLVM -O3. Write your answer inside a single <code>...</code> block. Inside <code>, write ONLY <step></step> blocks. Each step MUST follow this format: <step> ** Transformation ** : [Brief name of the optimization] ** Change ** : [A short description of the change applied to the code] </step> Do NOT output optimized IR. <ir>(Unopt Input LLVM IR)</ir> [ ] 12 Submission and Formatting Instructions for ICML 2026 B.2. Intent Refinement Prompt Template The intent refinement stage takes the initial optimization strategyS, which specifies a sequence of transformations for a given input IR programP, and refines it by grounding the strategy in concrete compiler analysis resultsR S . The template used in intent refinement stage is shown as follows: Please optimize the following code to outperform LLVM -O3. <code>(Unopt LLVM IR)</code> You may refer to the following advice, but feel free to adapt, extend, or deviate from it as you see fit. <advice>(Initial Strategy)</advice> The corresponding analysis info is below. <analysis>(Compiler Analysis)</analysis> You need to keep boundary checks. Please output the final optimization advice wrapped in < advice>...</advice>. B.3. Intent Realization Prompt Template The intent realization stage takes the refined optimization strategy ˆ Sand applies it to the unoptimized IR programPto generate the optimized IR program ˆ P . The template used in intent realization stage is shown as follows: Please optimize the following code to outperform LLVM -O3. <code>(Unopt LLVM IR)</code> You can refer to the following advice. <advice>(Refined Strategy)</advice> The corresponding analysis info is below. <analysis>(Compiler Analysis)</analysis> You need to keep boundary checks. Please output the full optimized LLVM IR wrapped in < code>...</code>. C. Prompt Template for LLM-based Optimizers To evaluate the performance of general-purpose LLM-based optimizers (GPT-5, Claude Haiku 4.5, and DeepSeek-V3.2), we use the following prompt template to guide the optimization process: Please optimize the following code to outperform LLVM -O3. <code>(Unopt LLVM IR)</code> You need to keep boundary checks. Please output the full optimized LLVM IR wrapped in < code>...</code>. D. Token Statistic Table 3 shows the data statistics about the number and token ofINT train ,INT val , andINT test used in Sec. 4.1. Specifically, we generated the dataset for optimization intent using INTtrain and INT val following the procedure described in Sec. 3.1. 13 Submission and Formatting Instructions for ICML 2026 Table 3. Data statistics about the number and token of INT train , INT val , and INT test . Total TokenAverage TokenMedian TokenMin TokenMax Token INT train Unoptimized IR8,219,9992,055.02,047.05794,304 Optimized IR5,531,1941,382.81,370.53593,373 Optimization Intent3,753,392938.6933.03311,719 INT val Unoptimized IR1,017,9052,035.82016.06854,035 Optimized IR691,1801,382.41,359.54253,220 Optimization Intent473,842947.7941.53211,692 INT test Unoptimized IR362,4551,812.31,572.56794,188 E. Experimental Details In Table 4, we provide all hyperparameter settings used in our experiments, including those for fine-tuning LLM Compiler FTD 7B and 13B for IR optimization, as well as fine-tuning LLM Compiler FTD 13B for intent formulation. In this work, we set the context window to 5K, meaning the total input and output must not exceed 5K due to resource limitations. Table 4. Hyperparameter settings. Model LoRA rank (r) LoRA α LoRA dropout Batch size Learning rate Target modules LLM Compiler FTD 13B/7B48160.0521× 10 −4 qproj, kproj, vproj, oproj F. Correctness Validation via Differential Testing Differential testing, also known as differential fuzzing, is a software testing technique that detects bugs by providing the same input to a series of similar applications (or to different implementations of the same application), and observing differences in their execution. Differential testing complements traditional software testing because it is well-suited to find semantic or logic bugs that do not exhibit explicit erroneous behaviors like crashes or assertion failures. In this work, we employ libFuzzer to generate a variety of inputs that cover diverse control flow paths, ensuring comprehensive testing of function behavior. F.1. Harness Generation for Differential Testing We leverage GPT-5 to automatically generate libFuzzer harnesses for each function pair. Specifically, for each LLVM IR file containing both a base function f and its optimized variant fopt, we prompt the LLM to synthesize a C++ fuzzing harness (fuzz.c) using the following prompt template: You are generating a C++ libFuzzer harness file named fuzz.c. Input: - A single LLVM IR (.l) file contains multiple function definitions. - Functions that should be differentially fuzzed appear as pairs: - base: <name> - opt : <name>_opt Both have identical signatures. - The .l file will be compiled and linked together with fuzz.c into one binary. Task: Generate fuzz.c that performs differential fuzzing between each (base,opt) pair. Hard requirements: 1) Output ONLY valid C++ code for fuzz.c. No markdown fences. No explanations. 2) Include necessary #includes. LLVM IR content: l_text 14 Submission and Formatting Instructions for ICML 2026 To illustrate this, consider the following example of a C++ fuzzing harness generated for a function pair numberOfOperations and numberOfOperationsopt: #include <cstdint> #include <cstddef> #include <cstring> int numberOfOperations(int); int numberOfOperations_opt(int); extern "C" int LLVMFuzzerTestOneInput(const uint8_t * data, size_t size) if (size < 4) return 0; int32_t in32; std::memcpy(&in32, data, 4); int arg = static_cast<int>(in32); int r_base = numberOfOperations(arg); int r_opt = numberOfOperations_opt(arg); if (r_base != r_opt) __builtin_trap(); return 0; The functionLLVMFuzzerTestOneInputis the entry point for libFuzzer, receiving input data generated by libFuzzer. The data is first parsed as a 32-bit integer, which is then passed as an argument to bothnumberOfOperationsand numberOfOperationsopt. If the results of the base and optimized functions do not match, the program triggers a trap usingbuiltintrap(), halting execution and indicating a mismatch. F.2. Differential Testing Binary Generation and Execution Each generated harness is compiled and linked with its corresponding LLVM IR to produce an instrumented fuzzing binary. The compilation pipeline consists of: •IR Compilation. Sincellcoperates on the backend, this step applies target-specific code generation and backend optimizations while preserving the IR-level transformations produced by the different optimizer. •Sanitized Linking. The generated assembly is linked with the fuzzing harness (fuzz.c) usingclang++, with comprehensive sanitizer instrumentation enabled via-fsanitize=fuzzer,address,undefined. These sanitizers respectively support coverage-guided input generation, detection of memory safety violations (e.g., buffer overflows and use-after-free), and identification of undefined behavior inconsistencies between the base and optimized implementations. Each instrumented binary is executed with 200,000 fuzzing iterations (-runs=200000). During execution, LibFuzzer continuously generates diverse test inputs guided by code coverage feedback, invoking both the base and optimized functions with identical inputs and comparing their behaviors. Any discrepancy in outputs, crashes, or sanitizer violations between the base and optimized functions indicates a semantic-altering transformation, thereby invalidating the optimization candidate. Only function pairs that successfully complete all 200,000 runs without detecting behavioral differences are validated as semantically equivalent optimizations. G. Performance Validation We measure performance using the same inputs generated by libFuzzer during correctness verification, thereby reflecting execution behavior across diverse control-flow paths. Based on this design, we transform validated differential fuzzing harnesses into standalone microbenchmarks for performance measurement. 15 Submission and Formatting Instructions for ICML 2026 Specifically, we automatically derive microbenchmark harnesses from the validated fuzzing harnesses through a sequence of source-level transformations. Starting from a differential fuzzing harness that invokes a base functionfand its optimized variantfopt, we first identify the corresponding function symbols (e.g.,numberOfOperationsand numberOfOperationsoptin Sec. F.1). We then rename the fuzzing entry pointLLVMFuzzerTestOneInputto a standard helper functiondecodeinput, which continues to parse raw input bytes into concrete arguments and performs a single invocation of both implementations. Next, we inject fine-grained timing instrumentation intodecodeinput. As illustrated in the example, we use clockgettime(CLOCKMONOTONICRAW)to record timestamps immediately before and after each call to the base and optimized functions.Execution time and invocation counts are accumulated in global counters (e.g., gtbaselinens,gtoptns). To prevent dead-code elimination, the addresses of return values are folded into a global volatile sink variable (gsink), ensuring that both function calls are preserved by the compiler. Finally, we synthesize a standalonemainfunction to drive benchmarking. This driver reads concrete inputs from the fuzzing corpus, performs a fixed number of warmup iterations (e.g., 1,000 executions excluded from measurement), and then executes a large number of timed iterations (default: 1,000,000). After execution, it reports the per-call average runtime of both the base and optimized implementations, along with the resulting speedup. All microbenchmarks are executed on an Intel(R) Xeon(R) Gold 6434 processor, and on average, each microbenchmark is evaluated using 16.6 distinct inputs from the fuzzing corpus. #include <cstdint> #include <cstddef> #include <cstring> #include <time.h> #include <fstream> #include <iostream> #include <vector> #include <cstdint> static inline uint64_t now_ns() struct timespec ts; clock_gettime(CLOCK_MONOTONIC_RAW, &ts); return (uint64_t)ts.tv_sec * 1000000000ull + (uint64_t)ts.tv_nsec; static uint64_t g_t_baseline_ns = 0; static uint64_t g_t_opt_ns = 0; static uint64_t g_n_baseline = 0; static uint64_t g_n_opt = 0; static volatile uintptr_t g_sink = 0; int numberOfOperations(int) asm("_Z18numberOfOperationsi"); int numberOfOperations_opt(int) asm("_Z18numberOfOperationsi_opt"); static int decode_input(const uint8_t * data, size_t size) if (size < 4) return 0; int32_t in32; std::memcpy(&in32, data, 4); int arg = static_cast<int>(in32); uint64_t __t0 = now_ns(); int r_base = numberOfOperations(arg); uint64_t __t1 = now_ns(); g_t_baseline_ns += (__t1 - __t0); g_n_baseline++; 16 Submission and Formatting Instructions for ICML 2026 g_sink ˆ= (uintptr_t)(const void * )&r_base; uint64_t __t2 = now_ns(); int r_opt = numberOfOperations_opt(arg); uint64_t __t3 = now_ns(); g_t_opt_ns += (__t3 - __t2); g_n_opt++; g_sink ˆ= (uintptr_t)(const void * )&r_opt; if (r_base != r_opt) __builtin_trap(); return 0; static std::vector<uint8_t> read_file(const char * path) std::ifstream ifs(path, std::ios::binary); if (!ifs) std::cerr << "Failed to open: " << path << " "; exit(1); return std::vector<uint8_t>( (std::istreambuf_iterator<char>(ifs)), std::istreambuf_iterator<char>() ); int main(int argc, char ** argv) if (argc < 2) std::cerr << "Usage: " << argv[0] << " <corpus_file> [iters] "; return 1; uint64_t iters = (argc >= 3) ? strtoull(argv[2], nullptr, 10) : 1000000ull; auto data = read_file(argv[1]); if (data.empty()) return 0; // donnot measure the warmup time uint64_t sb=g_t_baseline_ns, so=g_t_opt_ns, nb=g_n_baseline, no=g_n_opt; for (int i = 0; i < 1000; i++) (void)decode_input(data.data(), data.size()); g_t_baseline_ns=sb; g_t_opt_ns=so; g_n_baseline=nb; g_n_opt=no; for (uint64_t i = 0; i < iters; i++) (void)decode_input(data.data(), data.size()); double avg_b = g_n_baseline ? (double)g_t_baseline_ns / (double)g_n_baseline : 0.0; double avg_o = g_n_opt ? (double)g_t_opt_ns / (double)g_n_opt : 0.0; std::cout << "iters=" << iters << " "; std::cout << "baseline calls=" << g_n_baseline << " avg(ns/call)=" << avg_b << " "; std::cout << "opt calls=" << g_n_opt << " avg(ns/call)=" << avg_o << " "; if (avg_o > 0) std::cout << "speedup=" << (avg_b / avg_o) << "x "; std::cout << "(ignore) sink=" << (unsigned long long)g_sink << " "; return 0; H. Case Study H.1. Algorithm-level Optimization Program Description. ThechocolateFeastfunction implements a chocolate purchasing and wrapper exchange simulation. Given an initial budgetn, chocolate pricec, and exchange ratem(number of wrappers needed to exchange for one chocolate), it calculates the total number of chocolates that can be consumed. The algorithm proceeds in two phases: (1) 17 Submission and Formatting Instructions for ICML 2026 initial purchase using the budget, and (2) iterative wrapper exchanges until insufficient wrappers remain. Baseline Implementation (Unoptimized). The unoptimized IR implements this logic using explicit memory allocations, repeated loads and stores, and a loop that simulates wrapper exchanges one iteration at a time. define dso_local i32 @chocolateFeast(i32 noundef %0, i32 noundef %1, i32 noundef %2) #0 B0: %3 = alloca i32, align 4 %4 = alloca i32, align 4 %5 = alloca i32, align 4 %6 = alloca i32, align 4 %7 = alloca i32, align 4 store i32 %0, ptr %3, align 4 store i32 %1, ptr %4, align 4 store i32 %2, ptr %5, align 4 call void @llvm.lifetime.start.p0(i64 4, ptr %6) #2 %8 = load i32, ptr %3, align 4 %9 = load i32, ptr %4, align 4 %10 = sdiv i32 %8, %9 store i32 %10, ptr %6, align 4 call void @llvm.lifetime.start.p0(i64 4, ptr %7) #2 %11 = load i32, ptr %3, align 4 %12 = load i32, ptr %4, align 4 %13 = sdiv i32 %11, %12 store i32 %13, ptr %7, align 4 br label %B1 B1: %14 = load i32, ptr %5, align 4 %15 = load i32, ptr %7, align 4 %16 = icmp sle i32 %14, %15 br i1 %16, label %B2, label %B3 B2: %17 = load i32, ptr %7, align 4 %18 = load i32, ptr %5, align 4 %19 = sub nsw i32 %17, %18 store i32 %19, ptr %7, align 4 %20 = load i32, ptr %6, align 4 %21 = add nsw i32 %20, 1 store i32 %21, ptr %6, align 4 %22 = load i32, ptr %7, align 4 %23 = add nsw i32 %22, 1 store i32 %23, ptr %7, align 4 br label %B1 B3: %24 = load i32, ptr %6, align 4 call void @llvm.lifetime.end.p0(i64 4, ptr %7) #2 call void @llvm.lifetime.end.p0(i64 4, ptr %6) #2 ret i32 %24 LLVM-O3Optimization. LLVM-O3performs a series of standard IR-level optimizations on the original program. First, stack-allocated scalars are promoted to SSA form via mem2reg, eliminating redundant memory operations and lifetime intrinsics. Loop-invariant computations, such as the initial divisionq=n/c, are hoisted out of the loop, and loop-carried values are represented using PHI nodes. As a result, the optimized IR produced by LLVM-O3expresses the wrapper-exchange process more compactly in SSA form and removes unnecessary memory traffic. However, the core computation remains a loop that repeatedly updates the number of wrappers and consumed chocolates. define dso_local i32 @chocolateFeast(i32 noundef %0, i32 noundef %1, i32 noundef %2) local_unnamed_addr #0 B0: %3 = sdiv i32 %0, %1 %4 = icmp slt i32 %3, %2 br i1 %4, label %B2, label %B1 B1: 18 Submission and Formatting Instructions for ICML 2026 %5 = phi i32 [ %9, %B1 ], [ %3, %B0 ] %6 = phi i32 [ %7, %B1 ], [ %3, %B0 ] %7 = add nsw i32 %6, 1 %8 = sub i32 %5, %2 %9 = add i32 %8, 1 %10 = icmp slt i32 %9, %2 br i1 %10, label %B2, label %B1 B2: %11 = phi i32 [ %3, %B0 ], [ %7, %B1 ] ret i32 %11 INTOPT. In contrast, INTOPT goes beyond structural IR cleanup and performs algorithm-level reasoning. After applying the same foundational optimizations as LLVM-O3– such as SSA promotion, loop canonicalization, and invariant hoisting – INTOPT identifies a key mathematical property of the wrapper-exchange process. Specifically, whenm > 1andq > 0, the number of additional chocolates obtained through wrapper exchanges can be computed in closed form as: q− 1 m− 1 Based on this observation, INTOPT introduces a fast path that directly computes the total number of chocolates as: q + q− 1 m− 1 completely eliminating the loop in this common case. Importantly, boundary checks are preserved: the fast path is only taken whenm > 1, avoiding division-by-zero and ensuring semantic equivalence with the original program. For remaining cases, INTOPT falls back to a canonicalized loop that mirrors the original behavior, including non-termination whenm≤ 1. The refined strategy generated by INTOPT is as follows: - Promote all stack-allocated scalars to SSA (mem2reg) - Remove allocas (%3, %4, %5, %6, %7), loads/stores, and lifetime intrinsics. - Use incoming arguments directly and represent loop-carried values with PHI nodes. - Hoist loop-invariant computations and eliminate redundant loads - Compute the initial quotient once (%q = sdiv i32 %n, %c). - Use SSA values for the loop compare and updates instead of reloading memory. - Canonicalize the loop and add a preheader guard - Build a single loop header with PHIs for the running counts (consumed and wrappers). - Check in a preheader whether exchanges are possible (m <= wrappers). If not, return the initial quotient immediately. - Replace memory-based updates with SSA arithmetic and preserve flags - In the loop body, compute wrappers = wrappers - m + 1 and consumed = consumed + 1 using nsw where appropriate, matching the original semantics. - Add a fast closed-form path for m > 1 - When m > 1 and the initial quotient q > 0, the number of exchanges is floor((q - 1) / (m - 1)). Return q + floor((q - 1) / (m - 1)) without entering the loop. - Keep boundary checks: do not compute (q - 1) / (m - 1) unless m > 1 to avoid division by zero. For other cases, fall back to the loop, preserving original behavior (including non-termination for m <= 1). - Tighten function attributes - The optimized function performs only pure arithmetic and has no memory side effects. Mark it nounwind, willreturn, and memory(none). Keep target-specific attributes from the original. - Preserve loop metadata - Attach !llvm.loop.mustprogress to the loop latch to aid further optimizations. 19 Submission and Formatting Instructions for ICML 2026 The optimized IR generated by INTOPT is as follows: define dso_local i32 @chocolateFeast(i32 noundef %n, i32 noundef %c, i32 noundef %m) #0 entry: %q = sdiv i32 %n, %c %m_gt1 = icmp sgt i32 %m, 1 %q_gt0 = icmp sgt i32 %q, 0 %fast = and i1 %m_gt1, %q_gt0 br i1 %fast, label %fastpath, label %preheader fastpath: %q_minus1 = add nsw i32 %q, -1 %m_minus1 = add nsw i32 %m, -1 %extra = sdiv i32 %q_minus1, %m_minus1 %total = add nsw i32 %q, %extra ret i32 %total preheader: %can_loop = icmp sle i32 %m, %q br i1 %can_loop, label %loop, label %exit loop: %wrappers = phi i32 [ %q, %preheader ], [ %wrappers.next, %loop ] %consumed = phi i32 [ %q, %preheader ], [ %consumed.next, %loop ] %tmp = sub nsw i32 %wrappers, %m %wrappers.next = add nsw i32 %tmp, 1 %consumed.next = add nsw i32 %consumed, 1 %cond = icmp sle i32 %m, %wrappers.next br i1 %cond, label %loop, label %exit, !llvm.loop !9 exit: %result = phi i32 [ %q, %preheader ], [ %consumed.next, %loop ] ret i32 %result Discussion. This example highlights a fundamental distinction between traditional compiler optimizations and intent-driven optimization. LLVM-O3improves performance by restructuring the program within the same algorithmic framework, whereas INTOPT recognizes and exploits a higher-level mathematical invariant of the algorithm itself. By replacing an iterative process with a closed-form computation under well-defined conditions, INTOPT achieves an optimization that is fundamentally algorithmic rather than purely syntactic or structural. H.2. Global-coordinated Optimization H.2.1. REVERSEBIT Program Description. This function implements a data-dependent bit-reversal routine. Starting from an input integern, it iteratively constructs an output accumulator by (1) shifting the accumulator left by one bit, (2) appending the current least-significant bit ofn, and (3) shiftingnright by one bit. The loop terminates whenn=0. Intuitively, the function returns the bit-reversal of the significant prefix ofn: it reverses the bits ofnup to its most-significant 1-bit, while ignoring leading zeros. For example, n=6 (110b) yields 011b (=3). Baseline Implementation (Unoptimized). The unoptimized IR expresses the algorithm in a literal, step-by-step manner. It allocates stack slots for the input, the accumulator, and a temporary bit, and repeatedly performs memory loads/stores inside the loop. define dso_local noundef i32 @_Z12reverse_bitsi(i32 noundef %0) #0 B0: %1 = alloca i32, align 4 %2 = alloca i32, align 4 %3 = alloca i32, align 4 store i32 %0, ptr %1, align 4 call void @llvm.lifetime.start.p0(i64 4, ptr %2) #2 store i32 0, ptr %2, align 4 20 Submission and Formatting Instructions for ICML 2026 call void @llvm.lifetime.start.p0(i64 4, ptr %3) #2 br label %B1 B1: %4 = load i32, ptr %1, align 4 %5 = icmp ne i32 %4, 0 br i1 %5, label %B2, label %B3 B2: %6 = load i32, ptr %2, align 4 %7 = shl i32 %6, 1 store i32 %7, ptr %2, align 4 %8 = load i32, ptr %1, align 4 %9 = and i32 %8, 1 store i32 %9, ptr %3, align 4 %10 = load i32, ptr %3, align 4 %11 = load i32, ptr %2, align 4 %12 = or i32 %10, %11 store i32 %12, ptr %2, align 4 %13 = load i32, ptr %1, align 4 %14 = ashr i32 %13, 1 store i32 %14, ptr %1, align 4 br label %B1 B3: %15 = load i32, ptr %2, align 4 call void @llvm.lifetime.end.p0(i64 4, ptr %3) #2 call void @llvm.lifetime.end.p0(i64 4, ptr %2) #2 ret i32 %15 LLVM-O3Optimization. LLVM-O3performs canonical IR cleanups and loop simplification. It promotes stack-allocated variables to SSA (mem2reg), removes lifetime intrinsics, and represents the loop-carried state using PHI nodes: one PHI for the evolving input value and one for the accumulator. define dso_local noundef i32 @_Z12reverse_bitsi_opt(i32 noundef %0) local_unnamed_addr #0 B0: %1 = icmp eq i32 %0, 0 br i1 %1, label %B2, label %B1 B1: %2 = phi i32 [ %7, %B1 ], [ %0, %B0 ] %3 = phi i32 [ %6, %B1 ], [ 0, %B0 ] %4 = shl i32 %3, 1 %5 = and i32 %2, 1 %6 = or disjoint i32 %5, %4 %7 = ashr i32 %2, 1 %8 = icmp ult i32 %2, 2 br i1 %8, label %B2, label %B1 B2: %9 = phi i32 [ 0, %B0 ], [ %6, %B1 ] ret i32 %9 INTOPT. INTOPT identifies the loop as an instance of bit reversal and realizes it using a coordinated transformation that spans multiple abstraction levels: (1) semantic recognition of the loop’s algorithmic intent, (2) selection of hardware- mappable LLVM intrinsics, and (3) careful boundary handling to preserve defined behavior. Concretely, INTOPT replaces the entire loop with two compiler intrinsics:llvm.bitreverse.i32to reverse all 32 bits ofn, andllvm.ctlz.i32 (with iszeroundef=false) to compute the number of leading zeros. The refined strategy generated by INTOPT is as follows: - Replace the loop with two data-dependent instructions that the backend can map to hardware: llvm.bitreverse.i32 to reverse all 32 bits, and llvm.ctlz.i32 (with is zeroundef=false) to compute the number of leading zeros. The final result is lshr(bitreverse(n), ctlz(n)), which exactly matches the original loop’s semantics for non-negative inputs and avoids undefined behavior by guarding n==0. 21 Submission and Formatting Instructions for ICML 2026 - Keep a boundary check for n==0 to avoid shifting by the full width (which is undefined). This preserves correctness while enabling a branch-free fast path for all non-zero inputs. - Avoid allocas, lifetime intrinsics, and redundant loads/stores. Operate in SSA form and mark the function readnone, nounwind, and willreturn to let LLVM perform more aggressive optimizations and inlining if beneficial. - Note: The original IR uses an arithmetic right shift (ashr) on a signed int and a while( n != 0) termination condition, which leads to non-termination for negative inputs. If negative inputs are possible, you should constrain callers to pass non-negative values or switch the original algorithm to logical shifts. The optimized version below preserves the zero boundary check and provides well-defined behavior for all inputs, returning 0 for n==0 and a fast reverse for n>0. The optimized IR generated by INTOPT is as follows: define dso_local noundef i32 @_Z12reverse_bitsi(i32 noundef %n) local_unnamed_addr #0 entry: %iszero = icmp eq i32 %n, 0 br i1 %iszero, label %ret, label %fast fast: %brev = call i32 @llvm.bitreverse.i32(i32 %n) %clz = call i32 @llvm.ctlz.i32(i32 %n, i1 false) %res = lshr i32 %brev, %clz br label %ret ret: %r = phi i32 [ 0, %entry ], [ %res, %fast ] ret i32 %r H.2.2.Z3CONII Program Description. The function returns a Boolean-like integer (0or1) based on a set of guarded conditions. Intuitively, it checks whether the integerxequals the number of decimal digits ofy, under additional validity constraints:x > 0, y ∈ [1,m)wheremis a global threshold, and a special boundary case wheny = 0. The unoptimized implementation computes the digit count as⌊log 10 (y)⌋ + 1 and compares it with x, returning 1 iff they match; otherwise it returns 0. Baseline Implementation (Unoptimized). The unoptimized IR implements the logic using multiple basic blocks and stack-based temporaries. It computes⌊log 10 (y)⌋ + 1via integer-to-floating-point conversion, a math-library call tolog10, and a floating-point-to-integer cast. define dso_local noundef i32 @_Z3conii(i32 noundef %0, i32 noundef %1) #0 B0: %2 = alloca i32, align 4 %3 = alloca i32, align 4 %4 = alloca i32, align 4 store i32 %0, ptr %3, align 4 store i32 %1, ptr %4, align 4 %5 = load i32, ptr %3, align 4 %6 = icmp sle i32 %5, 0 br i1 %6, label %B1, label %B2 B1: store i32 0, ptr %2, align 4 br label %B10 B2: %7 = load i32, ptr %4, align 4 %8 = icmp eq i32 %7, 0 br i1 %8, label %B3, label %B5 B3: %9 = load i32, ptr %3, align 4 %10 = icmp eq i32 %9, 1 br i1 %10, label %B4, label %B5 22 Submission and Formatting Instructions for ICML 2026 B4: store i32 1, ptr %2, align 4 br label %B10 B5: %11 = load i32, ptr %4, align 4 %12 = icmp sle i32 1, %11 br i1 %12, label %B6, label %B9 B6: %13 = load i32, ptr %4, align 4 %14 = load i32, ptr @m, align 4 %15 = icmp slt i32 %13, %14 br i1 %15, label %B7, label %B9 B7: %16 = load i32, ptr %3, align 4 %17 = load i32, ptr %4, align 4 %18 = sitofp i32 %17 to double %19 = call double @log10(double noundef %18) #2 %20 = fptosi double %19 to i32 %21 = add nsw i32 %20, 1 %22 = icmp eq i32 %16, %21 br i1 %22, label %B8, label %B9 B8: store i32 1, ptr %2, align 4 br label %B10 B9: store i32 0, ptr %2, align 4 br label %B10 B10: %23 = load i32, ptr %2, align 4 ret i32 %23 LLVM-O3Optimization. LLVM-O3applies standard IR-level optimizations, including promoting stack variables to SSA form, collapsing redundant basic blocks, and simplifying control flow using PHI nodes andselectinstructions. These transformations reduce memory traffic and streamline the control flow. However, the optimized IR still relies on the floating-point digit-count computation using log10. define dso_local noundef range(i32 0, 2) i32 @_Z3conii_opt(i32 noundef %0, i32 noundef %1) local_unnamed_addr #0 B0: %2 = icmp slt i32 %0, 1 br i1 %2, label %B5, label %B1 B1: %3 = icmp eq i32 %1, 0 %4 = icmp eq i32 %0, 1 %5 = and i1 %4, %3 br i1 %5, label %B5, label %B2 B2: %6 = icmp sgt i32 %1, 0 %7 = load i32, ptr @m, align 4 %8 = icmp sgt i32 %7, %1 %9 = select i1 %6, i1 %8, i1 false br i1 %9, label %B3, label %B4 B3: %10 = uitofp nneg i32 %1 to double %11 = tail call double @log10(double noundef %10) #2 %12 = fptosi double %11 to i32 %13 = add nsw i32 %12, 1 %14 = icmp eq i32 %13, %0 br i1 %14, label %B5, label %B4 B4: br label %B5 B5: %15 = phi i32 [ 0, %B4 ], [ 0, %B0 ], [ 1, %B1 ], [ 1, %B3 ] 23 Submission and Formatting Instructions for ICML 2026 ret i32 %15 INTOPT. INTOPT performs a global-coordinated optimization by combining data-flow analysis with semantic reasoning over library calls. By tracing the provenance of the argument passed tolog10, INTOPT recognizes that the computation operates on the integer inputyand that its numeric domain is tightly constrained by preceding control-flow guards. This enables INTOPT to reinterpret the floating-point expression⌊log 10 (y)⌋ + 1as an integer digit-count operation rather than a general library call. Based on this reinterpretation, INTOPT replaces the floating-point conversion and library call with a semantically equivalent integer formulation. The digit count is computed exactly using a sequence of comparisons against constant powers of ten (e.g., y ≥ 10, 100, 1000,...), followed by accumulation of the Boolean results. The refined strategy generated by INTOPT is as follows: - Promote stack slots to SSA: Remove alloca/store/load of the input arguments and the result. Use the incoming arguments %0 and %1 directly and produce the result via straight SSA, returning directly from blocks. - Simplify the entry guards: Fold the initial "%0 <= 0" check into a single branch that returns 0 immediately. This avoids extra blocks and memory traffic. - Merge the two-step zero check: Replace the "%1 == 0" then "%0 == 1" chain with a single block returning zext(%0 == 1) when %1 == 0. This keeps the necessary boundary check for log10(0), but is branch-minimal. - Canonicalize the range check: Compute "inrange = (%1 >= 1) && (%1 < m)" as a single predicate and branch only once based on it. This preserves the boundary checks while cutting down on control flow. - Strength-reduce and eliminate the floating-point path: Replace the floor(log10(%1)) + 1 digit-count using the math library with an exact, branchless integer computation of decimal digits based on comparisons against constant powers of 10. This avoids FP conversion, the library call, and rounding concerns, and is typically much faster and more predictable than -O3’s FP-based codegen. - Reduce exits: Return directly from each decision point (early returns) rather than storing to a temporary and reading it back or building a complex control flow with PHIs. This enables simpler code generation and tail duplication when profitable. - Tighten attributes: Mark the function as readonly (it only reads m and does not write memory). Keep nounwind/mustprogress, which allows further optimization and better code generation without changing semantics. The optimized IR generated by INTOPT is as follows: define dso_local noundef i32 @_Z3conii(i32 noundef %x, i32 noundef %y) #0 entry: %cmp_x_le_0 = icmp sle i32 %x, 0 br i1 %cmp_x_le_0, label %ret0, label %check_y_zero ret0: ret i32 0 check_y_zero: %y_is_zero = icmp eq i32 %y, 0 br i1 %y_is_zero, label %y_zero_case, label %inrange_check y_zero_case: %x_is_one = icmp eq i32 %x, 1 %ret_y0 = zext i1 %x_is_one to i32 ret i32 %ret_y0 inrange_check: %ge1 = icmp sge i32 %y, 1 %mval = load i32, ptr @m, align 4, !tbaa !5 %ltm = icmp slt i32 %y, %mval %inrange = and i1 %ge1, %ltm br i1 %inrange, label %digits_compute, label %ret0b 24 Submission and Formatting Instructions for ICML 2026 ret0b: ret i32 0 digits_compute: %c1 = icmp sge i32 %y, 10 %c2 = icmp sge i32 %y, 100 %c3 = icmp sge i32 %y, 1000 %c4 = icmp sge i32 %y, 10000 %c5 = icmp sge i32 %y, 100000 %c6 = icmp sge i32 %y, 1000000 %c7 = icmp sge i32 %y, 10000000 %c8 = icmp sge i32 %y, 100000000 %c9 = icmp sge i32 %y, 1000000000 %t1 = zext i1 %c1 to i32 %t2 = zext i1 %c2 to i32 %t3 = zext i1 %c3 to i32 %t4 = zext i1 %c4 to i32 %t5 = zext i1 %c5 to i32 %t6 = zext i1 %c6 to i32 %t7 = zext i1 %c7 to i32 %t8 = zext i1 %c8 to i32 %t9 = zext i1 %c9 to i32 %s1 = add nuw nsw i32 %t1, %t2 %s2 = add nuw nsw i32 %t3, %t4 %s3 = add nuw nsw i32 %t5, %t6 %s4 = add nuw nsw i32 %t7, %t8 %s5 = add nuw nsw i32 %s1, %s2 %s6 = add nuw nsw i32 %s3, %s4 %s7 = add nuw nsw i32 %s5, %s6 %s8 = add nuw nsw i32 %s7, %t9 %digits = add nuw nsw i32 %s8, 1 %eqdigits = icmp eq i32 %x, %digits %retv = zext i1 %eqdigits to i32 ret i32 %retv Discussion.This example highlights the advantage of INTOPT ’s global-coordinated optimization guided by optimization intent. INTOPT recognizing the semantic role of the computation, validating its applicability via global guards, and selecting an implementation that better aligns with the target execution model. As a result, INTOPT performs an optimization that spans multiple abstraction layers, demonstrating how global coordination enables performance improvements beyond the reach of conventional compiler pipelines. 25