arXiv CSopen access

Archer: Towards Agentic Review for Compiler Optimizations

arXiv:2607.01808v1 [cs.SE] 2 Jul 2026

Archer: Towards Agentic Review for Compiler Optimizations Yunbo Ni

Shaohua Li

The Chinese University of Hong Kong [email protected]

The Chinese University of Hong Kong [email protected]

Abstract—Modern compilers are frequently updated, but expert review capacity is highly limited, leading to delayed integration and, in some cases, subtle semantic bugs entering the compiler codebase. Automating the code review process with modern general code review agents may be feasible, but it faces critical challenges due to compiler complexity. In this paper, we use LLVM as our target compiler and present Archer, the first automated agentic code review tool for compiler optimizations. Archer constrains the agentic review process from both ends by using obligations to guide analysis and a deterministic validation guard to admit only findings backed by executable evidence. We evaluated Archer on 70 open PRs and 328 closed PRs in LLVM from the last two months. The review results are shocking and concerning: Archer discovers that 21% of open PRs and 11% of closed PRs are buggy, i.e., introducing semantic bugs such as miscompilations in LLVM. Our findings expose a critical gap in the capacity for critical review in large compiler projects and demonstrate the practical value of Archer as an additional reviewer.

I. I NTRODUCTION Compilers are fundamental to the modern software ecosystem and are typically developed by large, distributed communities. For example, LLVM, one of the most widely used and mature compiler infrastructures, has more than 5,000 contributors working on components, with hundreds of commits integrated into the codebase every day [1]. However, this vibrant contribution flow hides a subtle bottleneck in its review capacity. The volume and complexity of incoming patches can outpace maintainers’ review bandwidth, leading to long review queues, delayed integration, and, in some cases, shallow or inconsistent feedback [2]. As noted by a lead maintainer of the LLVM project [3]: “lack of review capacity makes for a bad contributor experience, and can also result in bad changes making their way into the codebase.” This bottleneck is particularly problematic for compiler optimization patches. Unlike many ordinary software changes, an optimization patch must preserve the semantics of the source program while interacting with a long sequence of analysis and canonicalizations. Such missed semantic issues can lead to serious regression bugs [4], particularly miscompilation bugs, which are among the most critical and hardest-to-detect defects in compilers [5]. Even worse, experienced reviewers may overlook corner cases or fail to fully anticipate the impact of a change on downstream optimizations in a limited time. This naturally raises a research question: can this review process be automated to reduce the burden on maintainers?

Compiler optimization code review differs fundamentally from traditional compiler testing: it is patch-specific, semanticsoriented, and must provide useful feedback within the short turnaround of a pull request. By contrast, compiler testing typically relies on longer-running exploration and largely unguided search [6]. Recent progress in code agents suggests the possibility of assisting code review by automatically commenting on a patch [7]. Emerging tools, including Codex [8], Github Copliot [9] and the specialized review tool CodeRabbit [10], have begun to demonstrate this potential, mainly targeting general-purpose code review concerns such as style issues, maintainability problems, and common code smells. However, code review for compiler optimizations is substantially more demanding. Existing agentic review tools face two major challenges in this setting: (1) the gap between static textual context and complex semantics of compiler optimizations, and (2) the lack of executable and deterministic validation for textual suspicions. Below we elaborate on the two challenges: Challenge 1: Gap between static textual context and complex semantics of compiler optimizations. Existing agentic review tools largely follow a text-centric formulation, where they inspect the patch and retrieve surrounding repository context to generate review comments [11]. This formulation is useful for many implementation-level issues, but it is insufficient for compiler optimization review. A compiler optimization patch is part of a multi-stage semantic pipeline. To review a single optimization patch, the reviewer must reason not only about the local rewrite, but also about the possible semantic conditions under which the rewrite remains valid. For example, in LLVM, even a simple arithmetic transformation in InstCombine pass may become incorrect only under a particular combination of poison propagation, signedness constraints or overflow flags [12]. These dependencies are semantic rather than syntactic. They are therefore difficult to infer from textual exploration alone, even with retrieved repository context or API-level code navigation, because the relevant relation is not a call edge or a local data dependency, but a complex obligation at compiler semantic level. ➤

Challenge 2: Lack of executable and deterministic validation for textual suspicions. Existing LLM-based review tools usually produce natural-language comments about a patch [13]. For compiler optimization review, such textual ➤

comments are often insufficient. A verbose comment may point to a plausible bug, but without executable evidence, developers still need to determine whether the report is a real bug or a false positive. This burden is further amplified by the fact that LLMs can produce plausible but unfaithful explanations, rationalizing an incorrect conclusion with seemingly coherent analysis [14], [15]. This need for evidence is already reflected in real compiler review practice [16], [17], where LLVM developers are encouraged to accompany patches and comments with A LIVE 2 and OPT evidence. However, constructing such artifacts is non-trivial. A useful evidence must execute the specific optimization pass and further cover the changed lines of code in this certain patch, otherwise the result still leaves developers with additional manual validation work. This makes our goal fundamentally different from ordinary compiler testing, which may accept any newly discovered bug.

History Experience I reviewed vector before.

Dynamic Obligation Construction History vector-related bugs in InstCombine: #84025 ...

Implicit Context

Obligations

case Intrinsic:: vector_extract: { // ...‘mixed’ case

Guided Agentic Analysis search

IR/Verifier.cpp

Deterministic Validation Guard Patch-specific + Oracle-checkable

LangRef (vector.extract)

+

Evidence

Self-debug and verify Alive2

…

Strategies

idx is scaled if scalable.

Expert

langref

Opt

…

Archer

Reviewed and issue found.

Fig. 1: Example of how Archer conducts automated review on LLVM optimization PR in expert-like way.

➤ Our design. The key idea is to position the agentic review

process between compiler-specific semantic guidance on the input side and executable validation on the output side. This idea leads to two core mechanisms. On the input side, modern code agents can already search large repositories, but compiler optimization review needs guidance about which semantic relations are worth checking. Historical correctness fixes provide such guidance because they encode developers’ experience about fragile semantic interactions. Based on this observation, we propose dynamic obligation construction, which distills historical fixes into semantic obligations that guide the agent’s analysis beyond textual proximity or static context retrieval. On the output side, the agent’s analysis is still expressed in verbose natural language and may mix useful insights with incorrect reasoning. We therefore design a deterministic validation guard that converts textual analysis into executable, patch-specific evidence. The guard requires the agent to formulate actionable validation strategies, use them to guide proofof-concept generation, and report a finding only when the evidence exercises the relevant changed behavior in the patch. Based on this design, we propose Archer, the first automated agentic code review tool for compiler optimizations, designed to review semantically sensitive compiler patches. We implement Archer on top of mini-SWE-agent [18] by connecting its tool-call interface with LLVM-specific obligations and the deterministic validation guard. The design is frameworkagnostic and can be instantiated in other agent systems. To evaluate the effectiveness of Archer, we study real-world compiler review scenarios in LLVM, one of the most mature open-source compiler infrastructures. We collected a total of 398 PRs (70 open and 328 closed) from the LLVM GitHub repository over the two months prior to the time of writing. Archer identifies 51 PRs that contain semantic bugs, meaning that in the past two months, more than 21% of open PRs and around 11% of closed PRs in LLVM are buggy. This concerning finding points to a concrete review capacity gap, showing that semantic bugs are not only present in open PRs awaiting review, but also persist in closed PRs that have already undergone substantial manual review. This suggests

that the challenge is not merely insufficient review volume, but the difficulty of sustaining semantics-aware review at the scale of a large compiler project. In conclusion, this paper makes the following contributions: • We present Archer, the first agentic code review framework for compiler optimization patches, targeting semantic correctness bugs beyond generic review comments. •

We propose dynamic obligation construction as inputside semantic guidance, distilling historical correctness fixes into obligations that direct the agent toward fragile compiler-optimization semantics.

•

We design a deterministic validation guard as outputside evidence control, allowing the agent to report a finding only when its textual analysis is converted into executable, patch-specific evidence.

We implement and evaluate Archer on real LLVM PRs. Among 70 open and 328 closed PRs over the past two months, Archer finds 51 semantic bugs, showing its value for both ongoing review and bug discovery. Archer has been open-source in https://github.com/cuhk-s3/ Archer. We believe that this work highlights a promising direction for integrating agents into the review workflow for large-scale infrastructure software. •

II. I LLUSTRATIVE E XAMPLE AND M OTIVATION We use a real InstCombine pull request1 from LLVM to illustrate the kind of subtle semantic bugs targeted by Archer shown in Figure 1. This PR introduced a miscompilation bug in the LLVM, which was found by Archer. The core of this bug lies in the return-type semantics of the LLVM intrinsic vector.extract. In the following, we first describe how a human expert would review this PR and how this process motivates the design of Archer. ➤How human experts review this PR. A human reviewer

typically begins with prior development experience, accu1 https://github.com/llvm/llvm-project/pull/183329

Historical Correctness Fixes

Dynamic Obligation Construction LLVM PR

OP

Code Agent

Guided Agentic Analysis

Algorithm 1: Dynamic Obligation Construction

Multi-LLM + Validator

Coverage Buggy Evidence Strategy σ Deterministic Validation Guard (irsrc , irtgt)

Fig. 2: Design of high-level workflow for Archer.

mulated from working on the relevant compiler components over time. In this example, a reviewer familiar with the InstCombine pass and past vector-related issues would likely pay particular attention to vector lane semantics, since many historical bugs have arisen from subtle mistakes in this area. This corresponds to the first part of the human expert thinking model shown in the middle of Figure 1. Guided by this heuristic, the reviewer synthesizes an implicit context that extends beyond the local diff. To build a comprehensive model of vector.extract element, they may cross-reference formal specifications from the LangRef with semantically coupled subsystems, such as the return-type edge cases in IR/Verifier.cpp. Finally, the reviewer actively verifies it using external tools like A LIVE 2 and OPT, mirroring the actionable validation phases in Figure 1.

procedure B UILD O BLIGATION(D): Input: Historical correctness fixes D Output: Pass-level obligation base O 2 G ← G ROUP B Y PASS(D); // fixes by pass 3 O←∅ 4 foreach pass bucket P ∈ G do 5 VP ← ∅; // validated cases for P 6 foreach instance x ∈ P do 7 // Abstract: bug → obligation 8 o← E XTRACT O BLIGATION(x.issue, x.patch) 9 // Generate: obligation → IR 10 (irsrc , irtgt ) ← G ENERATE IRPAIR(o) // Validate: verify recovery 11 if P ROOF C HECK (irsrc , irtgt ) then 12 append (o, irsrc , irtgt ) to VP ; 1

13

14 15

// Summarize: high-level obligations by pass OP ← S UMMARIZE O BLIGATIONS(VP ); return O

➤How our Archer succeeds. The review workflow of Archer

follows the same high-level structure, but makes the process explicit and reproducible, as illustrated in the right part of Figure 1. Before review, Archer constructs pass-level obligations from historical correctness fixes through dynamic obligation construction. For this PR, the pre-built InstCombine obligations guide Archer to inspect whether the patch triggers vector lane semantics, rather than treating the change as a local implementation detail. Archer then starts to review the PR and analyze this patch. It calls on the search tools to collect patchcentered context like human experts and identifies several possible correctness issues. Under the deterministic validation guard, Archer cannot report all the suspicions directly. It first turns the analysis into actionable mutation strategies, including a strategy that varies the return type of vector.extract to challenge the transformation. The guard then uses patchrelated tests as seeds and guides Archer to mutate them into validation cases that still exercise the changed optimization. To activate the suspected return-type corner case, Archer further instantiates concrete inputs and validates the resulting source-target behavior with compiler-aware oracles. The final evidence shows that the patched compiler miscompiles a valid LLVM IR program. Archer reports the bug with a reproducer and supporting semantic analysis, and the developer later confirmed the issue and fixed it within one day. III. D ESIGN Figure 2 shows the high-level design of Archer. Archer’s design constrains agentic compiler review with input-side semantic guidance and output-side executable validation, realized through dynamic obligation construction and a deterministic validation guard. This section presents the full review

process by first describing how obligations are constructed in Section III-A, then how they guide agentic analysis in Section III-B, and finally how the guard turns analysis results into validated evidence in Section III-C. A. Dynamic Obligation Construction The goal of this component is to build an obligation base from historical correctness fixes that can guide future reviews with reusable compiler-semantic concerns. An obligation describes a semantic relation that an optimization pass should preserve, rather than specific implementation details. It consists of a set of semantic elements and transformation patterns that explains how these elements interact during optimization. ➤Recovering obligations with dynamic feedback. Existing

general code review systems [19], [20], [13] often augment review generation with retrieved textual artifacts through Retrieval-Augmented Generation [21] (RAG). Even when historical fixes are retrieved, they are typically used as static textual context. This is insufficient for compiler optimization review, as will be shown in our evaluation in Section V-D. The main reason is that it fails to recover the hidden semantics behind the implementation details. We take inspiration from compiler development practice to find the connection. When developers fix an optimization bug, they often attach a reproducer to make the hidden semantic relation observable, which suggests a natural way to recover semantics. Rather than treating a fix as a static patch, Archer uses reproducer generation as dynamic feedback to infer what semantic condition the fix was meant to preserve. A candidate obligation is retained only if it can explain a real reproducer whose transformation exposes the same kind of semantic issue behind the historical fix.

Extract from get_active_lane_mask with scalable extraction from fixed vector

Issue: nsw should be dropped Fix: drop in negation of select LLM A: Abstract Obligations How: The existing negated select possesses poison-generating flags LLM B: Generate and Verify IR Wrong! sub nsw i32 0, %b select i1 %a, i32 %b, i32 %c select i1 %a, i32 %c, i32 %b

LLM C: Summarize OInstCombine Element Poison-generating flags (nsw, nuw, exact…) Pattern Unconditional execution of conditionally guarded operations

Fig. 3: Example of how Archer automatically constructs passlevel obligations for InstCombine. ➤Organizing obligations by pass. We organize obligations

at the granularity of optimization passes. This organization follows the modular structure of modern compilers, where each pass implements a relatively specific class of transformations and maintains its own semantic assumptions. It also matches real-world review responsibilities, since a compiler optimization PR is usually reviewed by experts of a certain pass. Formally, Archer constructs an obligation base O, where each optimization pass P is associated with a validated obligation set OP . During review, Archer identifies the affected pass and loads the corresponding OP as semantic guidance. For the pass-level obligation set OP to serve as effective guidance during review, its obligations should satisfy three properties: • High-level. Pass-level obligations should not be tied to individual cases. Concrete bugs are often too specific and rare, making it difficult to match them directly to new patches. Compiler optimizations also continuously evolve, so obligations grounded in exact historical implementations can quickly become outdated. Therefore, constructed obligations should abstract away from case-specific details and capture reusable IR-level semantic elements and recurring transformation patterns. •

LLM-readable. The constructed obligations must be directly usable by LLM agents. Raw bug reports and fixes often contain much irrelevant information, such as outdated IR and LLVM source code, which is difficult for LLMs to read and reason about reliably [22]. Directly providing such raw materials can also introduce excessive low-level context, making them ineffective as review guidance.

Precise. The obligations extracted from historical fixes should capture the root causes of the original correctness issues. Otherwise, they may guide the agent toward irrelevant mutations or even misleading semantic concerns when reviewing new PRs. To satisfy the above requirements, Algorithm 1 uses a multiLLM pipeline. Given a collection of historical correctness fixes D, the algorithm works as follows: Step 1. Group Historical Fixes by Pass (line 2): The algorithm groups historical correctness fix instances D by •

…

active

inactive

<4 x i1> extract(4, vec)

<vscale x 4 x i1> extract(4, vec)

Fig. 4: Example of semantic rationale in Archer’s strategy.

optimization pass to obtain pass-specific buckets G. This ensures that each obligation set OP is constructed from fixes related to the same transformation context. Step 2. Abstract Candidate Obligations (lines 7–8): For each fix instance x in a pass bucket P , LLM A analyzes the fix to extract a candidate obligation o. At this stage, o is only a textual hypothesis about what semantic condition the historical fix was meant to preserve. Step 3. Generate Executable Reproducer (lines 9–10): LLM B attempts to materialize each candidate obligation o into an executable IR reproducer pair (irsrc , irtgt ). This step uses a reproducer to recover the hidden obligation.

Step* 4.**Poison-Generating Validate Candidate The FlagsObligations (`nsw`, `nuw`,(lines `exact`,11–12): `inbounds`, `disjoint`, `sames These flags are frequentlyis retained whenwith instructions are moved, reassociated, generated reproducer validated a compiler-aware their guarding conditions (like `select` instructions) are removed. The optimizat proof checker like A LIVE 2. If ir src and irtgt expose a misses that the conditionsthe guaranteeing flags may longer hold in the semantic difference, candidate these obligation is no treated context, leading to incorrect poison generation. as dynamically grounded and the triple (o, irsrc , irtgt ) is retained in VP . Otherwise, o is discarded because it cannot beUnconditional connected toExecution executable compiler behavior. Pattern 1: of Conditionally Guarded Operations The optimization pass struggles when converting conditional control flow

Step 5. Summarize Pass-Level Obligations (line 14): Finally, the validated candidates in VP are summarized by LLM C into the pass-level obligation set OP . This step abstracts away case-specific details from individual fixes while preserving reusable semantic elements and transformation patterns that can guide future reviews. At the end of the construction process, each optimization pass has a dedicated obligation base O that captures reusable and semantically validated review guidance. ➤Construction

Example. Figure 3 illustrates Algorithm 1 with an InstCombine example. We use one instance to show how a historical bug is converted into a pass-level obligation. For the selected instance x ∈ PInstCombine , the underlying issue is a miscompilation caused by the interaction between a select rewrite and the poison-generating nsw flag. LLM A abstracts the issue description and the fixing patch into a candidate obligation. In this case, the obligation captures that a transformation involving a negated select must re-check whether poison-generating flags remain valid after the rewrite. LLM B then instantiates this obligation into a candidate IR reproducer (irsrc , irtgt ). A LIVE 2 confirms that the reproducer exposes a semantic mismatch, so the triple (o, irsrc , irtgt ) is retained in VInstCombine . Finally, the validated set VInstCombine with other verified cases is summarized into OInstCombine by LLM C. The resulting pass-level obligations capture reusable IR-level semantic elements and transformation patterns, including the role of nsw element and the fragility of select-

define {ret_ty} @test_func({args}) { ...// generated IR } define {ret_ty} @main(i32 %argc,ptr %argv) { entry: %r = call {ret_ty} @test_func({args}) ret {ret_ty} %r }

Algorithm 2: Deterministic Validation Guard

procedure D ETERMINISTIC G UARD(σ, T, C − , C + ): Input: Strategy σ, PR-related tests T , pre-patch compiler C − , post-patch compiler C + Output: Accepted validation case c or ⊥ 2 Q ← M ATERIALIZE C ASES(σ, T ) 3 foreach source IR irsrc ∈ Q do Listing 1: Execution harness used by input-realized IR testing. + 4 irtgt ← T RANSFORM(C + , irsrc ) + 5 r ← P ROOF C HECK(irsrc , irtgt ) 6 if r is inconclusive then + based conditional rewrite pattern. Overall, the example shows 7 r ← T EST C HECK(irsrc , irtgt , σ) how dynamic obligation construction turns raw historical fixes 8 end into obligations that are high-level, LLM-readable, and precise. 9 if r exposes no semantic discrepancy then 10 continue B. Guided Agentic Analysis 11 end Given a reviewed PR, Archer prepares a patch-specific 12 if PATCH T RIGGERED (irsrc , C − , C + ) then + review harness with the changed compiler source tree, the 13 c ← (irsrc , irtgt , r) affected optimization pass, and its pass-level obligations OP . 14 return c The agent explores the compiler codebase through standard 15 end search and analysis actions, while using OP to focus on 16 end relevant semantic relations rather than open-ended repository 17 return ⊥ context. To support compiler-specific reasoning, Archer also provides access to the LLVM Language Reference [23] and OPT, allowing the agent to check IR semantics and validate ➤Ensuring patch triggering. Although an agent could synintermediate analysis during exploration. The output of this thesize LLVM IR tests from scratch, doing so is expensive stage is a set of actionable validation strategies. We denote and unreliable because generated IR often requires extensive each strategy as σ, which specifies a mutation method, serepair before it can exercise the intended optimization. Our mantic rationale, and the expected validation result. These design is based on a simpler observation: LLVM optimizationstrategies are then passed to the deterministic validation guard related PRs almost always come with tests [24], and those tests in Section III-C. already encode patch-relevant structure. However, exercising ➤Strategy Example. The following example illustrates an the pass is still not enough. A validation case should expose actionable strategy σ produced by Archer. Guided by Vector- behavior introduced by the reviewed patch, rather than an Combine obligations about vector scaling and lane, σ contains: unrelated latent bug in the same optimization pipeline. To enforce this requirement, Archer compares the case under • Mutation method. Make vector.extract extract a the unpatched compiler C − and the patched compiler C + . fixed vector from a scalable vector. A case is considered patch-triggering only when the semantic • Semantic rationale. As illustrated in Figure 4, in the + − concrete case of extracting <4 x i1> from <vscale discrepancy appears under C but not under C . x 4 x i1>, the patch may reason about the extracted lanes with an incorrect scaling assumption. As a result, lanes that should remain active may be treated as inactive. •

Expected validation result. The optimization incorrectly replaces the extracted mask with a zero vector.

C. Deterministic Validation Guard The goal of this component is to prevent the agent’s textual analysis from being reported unless it can be reduced to deterministic compiler evidence (irsrc , irtgt ) with properties: • Patch-triggering. irsrc must exercise the specific optimization pass and cover the changed behavior introduced by the PR. Otherwise, it may validate an unrelated transformation and cannot justify a finding for the current patch. •

Oracle-checkable. The source-target behavior between irsrc and irtgt must be checked by a compiler-aware oracle rather than by textual reasoning alone.

1

➤Complementary

validation oracles. LLVM developers commonly use A LIVE 2 to validate optimization correctness. Archer follows this practice with P ROOF C HECK, which checks source-target equivalence with A LIVE 2. However, A LIVE 2 is not complete for all real PRs, especially when patches involve unbounded loops, unsupported intrinsics, or solver-hard path conditions [12]. Therefore, Archer complements proofbased checking with execution-backed validation. Archer introduces T EST C HECK, a differential validation method over LLVM IR. Instead of treating execution as random testing, T EST C HECK uses the strategy σ to realize the suspected semantic condition with concrete inputs. Given irsrc and its transformed version irtgt , Archer places each IR body into the @test_func template in Listing 1, instantiates the placeholder fields {ret_ty} and {args} according to σ, and calls the function from @main with the same concrete inputs. Both programs are then executed with LLUBI, a UB-aware LLVM IR interpreter [25]. A mismatch in defined outputs or

TABLE I: Tool taxonomy in Archer. Category

Tool

Purpose

A LIVE 2 and LLUBI are pre-built as validation backends and are invoked by Archer within deterministic validation guards.

Context

search, langref

Build patch-local context.

B. Compiler-specific Toolkit

Validation

trans, verify, difftest

Turn suspicious strategies into validated evidence.

Management

workflow

Manage review process.

We design a set of compiler-specific tools for Archer to implement the core mechanisms described in Section III, as shown in Table I. Tool calls are one implementation choice, as the same capabilities can also be exposed through other agent workflows, such as agent skills. To keep the agent’s analysis grounded in the reviewed compiler version, Archer restricts the search and langref tools to search the local LLVM source tree and the look up LLVM Language Reference of the current PR. The agent is not allowed to access the Internet or search external repositories. To implement P ROOF C HECK and T EST C HECK in Section III-C, Archer provides verify and difftest, which invoke A LIVE 2 and LLUBI under the validation workflow in Algorithm 2. We also provide trans, which calls the prebuilt OPT to perform LLVM IR transformations. Finally, to reduce uncontrolled behavior in the agentic workflow [27], Archer provides a workflow tool to manage review-stage transitions and controlled termination, including exiting with a structured review report.

undefined-behavior is treated as executable semantic evidence. This design allows Archer to validate cases that are hard for proof-based checking, while still keeping the validation tied to the specific semantic condition proposed Archer. Algorithm 2 shows how Archer deterministically decides whether a validation strategy σ can find semantic bugs. Here, deterministic means that Archer cannot report based on textual judgment alone; the guard returns an accepted case c only if σ can be materialized into executable evidence. Otherwise, the algorithm returns ⊥, and no report is allowed: Step 1. Materialize candidate cases (line 2): The guard materializes σ into a set of candidate source IR programs Q using PR-related tests T as seeds. This keeps case generation close to the reviewed patch instead of generating arbitrary LLVM IR from scratch. Step 2. Check oracle checkable (lines 3–11): For each irsrc ∈ Q, the post-patch compiler C + produces the transformed + IR irtgt . The guard first applies P ROOF C HECK; if the result is inconclusive like timeout or A LIVE 2 errors, it falls back to T EST C HECK. Candidates that do not expose differences are discarded. Step 3. Check patch triggering (lines 12–17): For candidates with a semantic difference, the guard checks whether the difference is introduced by the reviewed patch by comparing C − and C + . Only patch-triggering candidates are accepted as validation cases c. If none is accepted, the guard returns ⊥. When the guard accepts a case, Archer reports the validated + IR pair (irsrc , irtgt ) together with concise analyses of the bug trigger and the fix weakness. The final output is evidence-first rather than a verbose review comment. We provide a concrete example with the guard in Section V-E. IV. I MPLEMENTATION This section discusses two practical implementation aspects when deploying Archer to review LLVM optimization PRs. A. Dataset and Execution Environment Archer uses the GitHub REST API [26] to monitor LLVM PRs with new updates and automatically collect the inputs needed for review. For each selected PR, Archer extracts the patch diff, changed files, commit metadata, affected optimization pass, and tests attached to or associated with the PR. It then prepares a patch-specific LLVM environment by building both the pre-patch and post-patch versions of LLVM.

V. E VALUATION In this section, we evaluate the effectiveness and design choices of Archer through the following research questions: • RQ1 (Real-world PR review). How does Archer perform as a reviewer on the real-world LLVM PRs? •

RQ2 (Effectiveness). How effective is Archer at identifying semantic bugs on a curated regression benchmark of bisected LLVM PRs compared to different approaches?

•

RQ3 (Ablation Analysis). How important are obligations and validation guard in Archer, and how do different obligation construction design choices affect its effectiveness?

•

RQ4 (Case study). What bug patterns can Archer uncover, and how does it perform beyond existing tools?

A. Evaluation Setup Datasets. We construct two datasets in our evaluation: • Real-world dataset. This dataset consists of all LLVM PRs related to middle-end optimization submitted between December 31st, 2025 and February 28th, 2026, identified by labels, such as llvm:transform and llvm:analysis. In total, it contains 398 PRs, including 70 open PRs and 328 closed PRs. Figure 5 shows the statistics of these PRs, including the number of changed lines in the LLVM source code and the number of tests. On average, PRs contain 70.7 lines of code and 11 test cases, indicating a high degree of complexity. • Regression dataset. This dataset is built from LLVM middle-end optimization issues labeled as miscompilation between January 1st, 2024 and October 1st, 2025. We perform commit-level bisection on each issue to identify

Avg: 70.7 lines

Frequency

90 80 70 60 50 40 30 20 10 00

Frequency

140 120 100 80 60 40 20 00

60

120

180

TABLE IV: Affected components.

TABLE II: Status of bugs.

240

Patch changed lines per PR

300+

Status

Open

Closed

Total

Component

Not Planned Unconfirmed Confirmed Fixed

0 4 4 7

3 0 7 26

3 4 11 33

Total

15

36

51

Peephole Optimizations Vectorization Optimization Loop Transformations Value Range Analysis Coroutines SLP Vectorization Alias Analysis CFG Transformations Inlining Interprocedural Analysis Interprocedural Optimization Constant Propagation Global Value Numbering Pass Management

Avg: 11.0 tests TABLE III: Symptoms of bugs.

10 20 30 40 50 60 70 80 90+

Number of tests per PR

Fig. 5: Distributions of real-world PRs.

Symptom

Open

Closed

Total

Crash Miscompilation

3 12

14 22

17 34

Total

15

36

51

the corresponding bug-inducing patch, resulting in 47 cases in this dataset. Obligation Construction. We collect LLVM miscompilation bugs between January 2017 and February 2026, extract the associated bug-fixing PRs or commits, and obtain 317 candidate patches in total. From these patches, Archer constructs validated obligations for 45 optimization passes with 188 validated cases. For experiments on both the real-world and regression datasets, we explicitly exclude any historical cases that overlap with the evaluation instances before constructing the obligation base, ensuring that no benchmark leakage occurs. Agent Configuration. Each review run is limited to 500 agent rounds and 10M tokens. We allow at most 250 invocations for each tool. We equip Archer with three different recent models: Gemini-3.1-Pro-Preview-Custom-Tools[28], DeepSeekV3.2 [29], and Qwen3.5-Plus [30]. For mini-SWE-agent [18], we use its latest V2 version. For the closed-source commercial tools GitHub Copilot [9], CodeRabbit [10] and Greptile [31], we use their Pro versions and keep their default configurations unchanged. For general code agent frameworks, we choose OpenAI Codex [8] with its latest model ChatGPT-5.5 [32]. Environment. We conducted all our evaluations on one Linux server running Ubuntu 20.04 LTS. It is equipped with an AMD EPYC 7742 64-core CPU and 256GB RAM. B. RQ1: Real-World PR Review A central goal of Archer is to support real-world deployment by helping relieve the shortage of review capacity in large compiler projects. To assess this capability, we deploy Archer in the LLVM community and use it to review 398 pull requests in real-world dataset, including 70 open PRs and 328 closed ones. In short, Archer discovers that more than 21% of the open PRs and 11% of the closed PRs in the LLVM compiler are buggy. Below, we provide a detailed report and analysis. Number of Bugs. Table II summarizes the status of all bugs reported by Archer. In total, Archer reported 51 semantic bugs during the two-month PR review. Among them, 33 bugs (69%) have already been fixed, and 11 bugs (23%) have been

#Bugs 10 9 7 5 4 3 2 2 2 2 2 1 1 1

confirmed by developers but deferred for future resolution. These results demonstrate not only the effectiveness of Archer in uncovering semantic bugs, but also the willingness of LLVM developers to take Archer’s findings seriously. Only three reports are marked as Not Planned, showing a low falsepositive rate of 6%. Two of them are related to a deprecated feature in latest LLVM 23.0 that Archer still considered semantically relevant, while the third stems from an incorrect interpretation of nondeterministic semantics. In fact, these cases are acceptable and can be avoided with the continuous development of Agneis, which we will discuss further in Section VI. Nevertheless, the significant number of new bugs identified by Archer demonstrates its strong capability. As noted by a lead maintainer in LLVM: “Thanks for your work on this! I’ve looked at many of these reports, and I think they’re quite useful. There are few false positives, and the analysis is generally on-point.” Symptoms of Bugs. Table III summarizes the symptoms of the reported bugs. These bugs fall into two main categories: (1) Crash: the compiler encounters an internal failure during optimization, such as an assertion violation or other runtime error. (2) Miscompilation: the compiler silently generates incorrect code without any explicit failure. As shown in the table, most of the reported bugs are miscompilation bugs, which is particularly concerning as miscompilation is widely regarded as the most serious class of compiler bugs [5]. Detecting such miscompilation bugs requires strong semantic reasoning. Affected compiler components. Table IV summarizes the compiler components affected by the bugs identified by Archer. As shown in the table, Archer uncovers semantic bugs across a diverse set of compiler components, suggesting that its review capability benefits from the pass-level obligation design and extends beyond any single optimization category. A substantial portion of the reported bugs arise in peephole optimizations, which is consistent with prior empirical findings on optimization bugs [33]. We also observe many bugs in loop optimizations and vectorization, where semantic correctness is often harder to validate and many bugs cannot be captured by

difftest search

context 0

verify langref

2000 4000 6000 8000 10000 12000 Calls

Fig. 6: Distributions of tool calls.

base wo all rag

Gemini-3.1-Pro DeepSeek-V3.2

Qwen3.5-Plus

Fig. 7: Bugs found with different models.

Alive2 alone, which will be discussed deeper in Section V-E. Review process analysis. We use Gemini-3.1-Pro from Google as the underlying model, which was among the strongest frontier models available at the time of our study. Across 398 review cases, the end-to-end review process costs $988.7 in total, averaging $2.5 per case. The review consumes 5,054,201 tokens for each case, and each case takes 877 seconds on average. This overhead is moderate and remains practical for real-world review settings with bounded budgets. Figure 6 further shows the distribution of tool calls throughout the review process. As expected, verification tools dominate the overall usage. Notably, during verification, difftest is invoked more often than verify, highlighting that T EST C HECK design choice is practical considering the limiation of P ROOF C HECK. We further analyze the role of context-retrieval tools in successful bug findings. On average, Archer invokes code search tools to retrieve 4, 800 additional lines of code for context construction, and consults langref 1.5 times to confirm semantic details. C. RQ2: Effectiveness In this RQ, we compare Archer with other approaches on the regression dataset that contains PRs with known bugs. This evaluation allows us to quantify Archer’s effectiveness. We configure Archer with different models to understand the impact of the underlying LLM models. ➤Comparing Archer itself using different models. We first try to understand how Archer performs when equipped with different LLMs. We provide three alternatives, i.e., one closedsource model Gemini-3.1-Pro, and two open-source models Deepseek-V3.2 and Qwen3.5-plus. The first three base bars in Figure 7 show that Gemini-3.1Pro finds the largest number of bugs, followed by Qwen3.5Plus and DeepSeek-V3.2. This indicates that stronger foundation models lead to better review outcomes. For the relatively weaker open-source models, they are also able to find nontrivial numbers of semantic bugs under Archer, suggesting that the effectiveness of Archer is not tied to a single proprietary model. Figure 9 shows the bug overlaps. Gemini-3.1-Pro covers all bugs found by the other two models. ➤Comparing Archer with general LLM-based methods. In this comparison, we want to understand how general LLM and coding agent perform on the compiler review task. We choose two representative baselines as follows.

•

Found Cases (#)

validation trans

Found Cases (#)

workflow

management

20 18 16 14 12 10 8 6 4 2 0

20 18 16 14 12 10 8 6 4 2 0

E ct it ile zz er ex ot Arch Cod CopoildeRabb GreptOptimu MSW Dire C

Fig. 8: Comparison with different tools.

Direct LLM-based query (Denoted as Direct). Deepseek-V3.2 is used directly for review without the agentic framework, obligations, or validation guard.

Open-source code agents (Denoted as MSWE). We use mini-SWE-agent with Deepseek-V3.2 serves as the representative open-source agent framework. As shown by the Direct and MSWE bars in Figure 7. The Direct setting finds no bug while the mini-SWE-agent (MSWE) setting can only find one bug. This suggests that although general LLMs and code agents excel at many tasks, it is very hard for them to do complex tasks likes compiler code review, which requires pre-built environment, fine-grained domain obligations and necessary validation suite. •

➤Comparing

Archer with the traditional fuzzing-based tool. Optimuzz [34] is a targeted testing tool for LLVM. As shown in Figure 7, it successfully detects three bugs that are all covered by Archer as well. However, Optimuzz fails to start its fuzzing process on 23 out of 47 cases due to the CFG construction failures. The main reason is that Optimuzz requires to instrument LLVM by matching certain CFG structures, which are often not available in real-world PRs. ➤Comparing Archer with the commercial AI review tools.

We further compare Archer with commercial agentic review tools on the regression dataset. These tools are strong generalpurpose coding and review systems, and have shown impressive capabilities across many real-world software engineering tasks. Note that although Archer is currently implemented as a prototype on top of a simple agent framework, its core mechanisms are framework-independent and can be integrated into other agentic review systems. We evaluate four widely used commercial tools, including Codex, GitHub Copilot, CodeRabbit, and Greptile. Codex and GitHub Copilot are general-purpose code agents that can be prompted for review, while CodeRabbit and Greptile are designed specifically for code review. Since these tools typically produce long naturallanguage reports rather than executable evidence, we manually inspect each report and check whether it identifies the groundtruth semantic bug. As shown by the Codex, Copilot, CodeRabbit, and Greptile bars in Figure 7, all commercial tools perform poorly on the regression dataset. Most reports focus on superficial implementation concerns, such as missing API parameters, style issues,

between the patch under review and historical patches to get the most similar top-3 cases, and provide them directly.

30000 25000 20000 15000 10000 5000 0

all: We provide the full set of validated historical cases to the model without any summarization or structuring. The two alternative settings in Figure 7 correspond directly to the design principles introduced in Section III-A. The rag setting represents a static texual alternative that directly retrieves historical issues similar to the patch under review. This design weakens the high-level and precise properties, since the retrieved context remains unverified and tied to concrete past cases rather than abstracting reusable semantic patterns. The all setting provides the full set of validated historical cases without summarization or structuring. This weakens the LLM-readable property, since the model must process a large amount of low-level and case-specific material. These two alternatives therefore test whether obligations should be abstracted, rather than exposed as raw historical evidence. As shown in Figure 7, the final base design consistently outperforms both rag and all across models. This indicates that effective review guidance should not simply retrieve similar historical bugs at textual level, but should instead dynamically distill them into compact and reusable semantic obligations. A further consideration is context efficiency. Prior work shows that overly long inputs can dilute salient signals even when they remain within the nominal context budget [35]. In agentic review, guidance quality is therefore limited not only by relevance, but also by the practical usability of the context. Figure 10 compares context length across different settings. Our constructed obligations, denoted by the Base bar, are consistently more compact than both alternatives, indicating a substantial reduction in context size.

Knowledge Length (chars)

125000 100000 •

Base

RAG

All

Fig. 9: Bug overlap across Fig. 10: Distributions of differArcher with different models. ent knowledge length. incomplete comments, or generic maintainability suggestions, while missing the semantic correctness bug introduced by the optimization patch. A major practical issue is verbosity. The generated reports often contain many plausible but unverified observations, making manual inspection time-consuming. After analysis, we find that most issues are false positives or irrelevant to the ground-truth regression. More seriously, these tools rarely provide executable evidence that links a reported concern to the changed optimization behavior, which makes them impractical for compiler optimization review. D. RQ3: Ablation Analysis We conduct the ablation study to examine (1) the contribution of obligations, (2) the contribution of deterministic validation guard, and (3) the impact of obligation construction design choices. ➤Contribution of obligations. We create a variant, denoted

wo, by removing all obligations during review. Figure 7 shows a consistent gap between the base and wo settings in all three models, confirming the importance of obligations in semantic compiler review. Removing obligations reduces the number of bugs found by nearly half across all models. This result suggests that the model alone is often unable to infer the bugtriggering elements and semantic patterns behind a patch. ➤Contribution of deterministic validation guard. The com-

parison between the wo setting of DeepSeek-V3.2 and the MSWE bars further highlights the importance of our deterministic validation guard. Both settings use the same underlying model and framework, but differ in the available tool support. The wo variant of Archer still finds three bugs, whereas MSWE finds only one. This gap indicates that tool access alone is insufficient without carefully designed validation guard. ➤Impact

of obligation construction design. The goal of dynamic obligation construction is to provide concise and effective guidance for both analysis and verification. Our final design, shown in Algorithm 1, uses three LLM stages to transform historical issue-fix instances into structured passlevel obligations. Theoretically, there can be an arbitrary number of ways of using the historical issue-fix instances to assist code review. Below, we provide two straightforward alternatives and compare them with our design. • rag: For each PR under review, we use the RAG idea to retrieve historical cases. We use the Jaccard similarity

E. RQ4: Case Study We present a real-world case study from an LLVM PR in Figure 11. The PR attempts to relax the conditions for hoisting loop-invariant add/sub expressions out of loops when the comparison predicate is eq/ne. While rewriting IV + X == C into IV == C - X is arithmetically sound due to the bijection of modular arithmetic, the patch overlooks the semantics of the samesign flag on the icmp instruction. By keeping the samesign flag unchanged, the transformation introduces a semantic gap. Guided by obligations for InstCombine pass, Archer generates a targeted strategy focusing on cases related to an icmp samesign instruction. This strategy formulates a specific hypothesis: the rewrite may invalidate the samesign property and thereby produce a poison value. Archer then concretizes this strategy into an executable evidence within the deterministic validation guard. Archer successfully synthesizes a concrete loop that exposes the sign mismatch. The final successful evidence, shown in Figure 11, fixes the initial loopcarried value %iv = -1 and executes the test with %x = 1: • Original IR (Figure 11a): The first iteration computes %arith = -1 + 1 = 0. The comparison icmp samesign eq 0, 1 remains valid because both 0 and

define i32 @src(i32 %x) { loop: %iv = phi i32 [ -1, %entry ], ... %arith = add i32 %iv, %x ; %x=1 -> %arith=0 (non-neg) ; But samesign(0, 1) is true (both >= 0) %chk = icmp samesign eq i32 %arith, 1 br i1 %chk, label %exit, label %loop }

(a) Original: samesign(0, 1) is Valid.

define i32 @tgt(i32 %x) { %inv.op = sub i32 1, %x ; x=1 -> inv=0 loop: %iv = phi i32 [ -1, %entry ], ... ; LLUBI ERROR: Branch on poison! ; -1 is negative, 0 is non-negative. %chk = icmp samesign eq i32 %iv, %inv.op br i1 %chk, label %exit, label %loop }

(b) Transformed: samesign(-1, 0) is Poison.

Fig. 11: The rewrite iv+x==1 → iv==1-x invalidates samesign. When x=1 and iv=-1, the original compare is samesign(0, 1) (valid), but the transformed one is samesign(-1, 0) (poison). 1 are non-negative, allowing the loop to continue normally after evaluating to false. Transformed IR (Figure 11b): The hoisted invariant becomes %inv.op = 1 - 1 = 0, and the comparison transforms to icmp samesign eq %iv, %inv.op. During the first iteration, this evaluates to samesign(-1, 0). Since −1 (negative) and 0 (nonnegative) have different signs, the samesign constraint is violated. The result becomes poison, triggering immediate undefined behavior. This case also highlights the necessity of Archer’s multicheck approach. When this loop is submitted to verify tool, it incorrectly reports the transformation as correct with Alive2. In contrast, difftest tool using LLUBI clearly identifies the discrepancy, showing that the original program terminates normally while the transformed version fails with a “Branch on poison” error. This divergence indicates that Alive2’s reasoning is imprecise for this specific loop structure. Such findings underscore the value of combining P ROOF C HECK alongside T EST C HECK within Archer. •

piler components. This line of work differs from most prior compiler-testing techniques, including generation-based compiler testing [36], [37], [38], [39], [40] and mutation-based testing [41], [42], [43], [44], [45], [46]. It leverages semantic information extracted from compiler code to guide testing toward particular components or behaviors. Optimuzz [34] is the first work to apply directed fuzzing to validate compiler optimizations, combining directed grey-box fuzzing with translation validation. TargetedFuzz [47] targets individual optimizations to complement pipeline-based testing. It automatically generates language-agnostic mutators to exercise specific optimization-composition patterns. MopFuzzer [48] focuses on triggering sets of optimizations and implements 13 mutators to maximize optimization interactions in JVM compilers. Archer differs from targeted compiler testing by focusing on singlepatch review, where evidence must be semantically tied to the specific optimization change rather than merely triggering a target transformation. This difference is also reflected in our evaluation. As shown in Section V-C, targeted testing tools such as Optimuzz are less effective.

gap of Archer. Our evaluation on the regression dataset in Section V-C reveals that Archer still has a significant gap in recall, which motivates the following future directions to further improve compiler code review. ➤Obligations can be continuously refined. Obligations in Archer are not fixed. For failed cases, we can feed the case and the corresponding review output back to the agent and let it revise the relevant obligations automatically. The revised knowledge is then checked against the regression benchmark to verify without hurting performance on existing ones. ➤Review trajectories reveal optimization opportunities. Some limitations come from agent behavior rather than missing knowledge. In our traces, the agent sometimes wastes budget on repeated tool calls or low-yield exploration. A natural next step is to train on review trajectories, so that the agent can use its budget more efficiently and behave more like experienced developers during review.

LLMs for Code Review. Automated code review has traditionally focused on tasks such as review comment generation and automatic resolution of reviewer comments [49], [50]. A recent empirical study [51] emphasizes that current codereview automation techniques are highly task-dependent and that aggregate metrics often obscure where these systems actually succeed or fail. With the rise of LLMs, code review systems have increasingly shifted from single-shot generation to more structured workflows. CodeAgent [52] proposes a multi-agent architecture for code review for tasks such as commit-message consistency checking, vulnerability identification, style validation, and revision suggestion. Our setting differs from existing LLM-based code review systems in two key aspects. They generally rely on static patch inspection, which offers limited semantic observability for correctnesscritical changes. To address these challenges, Archer combines obligations with a deterministic validation guard for executable evidence, which is demonstrated to be useful with results in Section V-C.

VII. R ELATED W ORK

VIII. C ONCLUSION

Targeted Compiler Testing. Recent research has proposed a targeted approach for validating and testing specific com-

We presented Archer, a compiler-specific semantic review system for optimization PRs. Across 398 recent LLVM PRs,

VI. D ISCUSSION ➤Recall

Archer identified 51 semantic bugs, showing that it can improve ongoing review and complement manual inspection by surfacing issues that are easy to miss. More broadly, we believe this design points to a promising direction beyond compilers. For large infrastructure software with complex semantics, effective automated review will likely require not only strong models, but also domain-specific obligations, validation, and workflows that turn semantic suspicion into actionable evidence. DATA -AVAILABILITY S TATEMENT Our research artifacts are publicly available at: https:// github.com/cuhk-s3/Archer. R EFERENCES [1] LLVM, “Contributors to llvm/llvm-project,” 2026, accessed: 202602-18. [Online]. Available: https://github.com/llvm/llvm-project/graphs/ contributors [2] ——, “Contributors to llvm/llvm-project,” 2026, accessed: 202603-11. [Online]. Available: https://insights.linuxfoundation.org/project/ llvm-llvm-project [3] N. Popov, “Llvm: The bad parts,” 2026, accessed: 2026-02-18. [Online]. Available: https://www.npopov.com/2026/01/11/LLVM-The-bad-parts. html [4] X. Zhu and M. Böhme, “Regression greybox fuzzing,” in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’21, 2021, p. 2169–2182. [Online]. Available: https://doi.org/10.1145/3460120.3484596 [5] J. Chen, J. Patra, M. Pradel, Y. Xiong, H. Zhang, D. Hao, and L. Zhang, “A survey of compiler testing,” ACM Comput. Surv., vol. 53, no. 1, 2020. [Online]. Available: https://doi.org/10.1145/3363562 [6] X. Zhu, S. Wen, S. Camtepe, and Y. Xiang, “Fuzzing: A survey for roadmap,” ACM Comput. Surv., vol. 54, no. 11s, 2022. [Online]. Available: https://doi.org/10.1145/3512345 [7] U. Cihan, V. Haratian, A. İçöz, M. K. Gül, Ö. Devran, E. F. Bayendur, B. M. Uçar, and E. Tüzün, “Automated code review in practice,” in 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2025, pp. 425–436. [8] OpenAI, “Codex | ai assistant work and code,” 2026, accessed: 2026-06-25. [Online]. Available: https://chatgpt.com/codex [9] GitHub, “Githhub copilot - your ai pair programmer,” 2026, accessed: 2026-06-25. [Online]. Available: https://github.com/features/copilot [10] C. Inc, “Ai code reviews | coderabbit,” 2026, accessed: 2026-03-26. [Online]. Available: https://www.coderabbit.ai [11] Y. Zhang, Y. Zhang, Z. Sun, Y. Jiang, and H. Liu, “Laura: Enhancing code review generation with context-enriched retrieval-augmented llm,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2025, pp. 2983–2995. [12] N. P. Lopes, J. Lee, C.-K. Hur, Z. Liu, and J. Regehr, “Alive2: bounded translation validation for llvm,” in Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation, ser. PLDI 2021, 2021, p. 65–79. [Online]. Available: https://doi.org/10.1145/3453483.3454030 [13] T. Sun, J. Xu, Y. Li, Z. Yan, G. Zhang, L. Xie, L. Geng, Z. Wang, Y. Chen, Q. Lin, W. Duan, K. Sui, and Y. Zhu, “Bitsai-cr: Automated code review via llm in practice,” in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, ser. FSE Companion ’25, 2025, p. 274–285. [Online]. Available: https://doi.org/10.1145/3696630.3728552 [14] M. Turpin, J. Michael, E. Perez, and S. R. Bowman, “Language models don’t always say what they think: unfaithful explanations in chain-ofthought prompting,” in Proceedings of the 37th International Conference on Neural Information Processing Systems, ser. NIPS ’23, 2023. [15] A. Madsen, S. Chandar, and S. Reddy, “Are self-explanations from large language models faithful?” in Findings of the Association for Computational Linguistics: ACL 2024. Association for Computational Linguistics, 2024, pp. 295–337. [Online]. Available: https://aclanthology. org/2024.findings-acl.19/

[16] LLVM, “Instcombine contributor guide,” 2026, accessed: 2026-03-26. [Online]. Available: https://llvm.org/docs/ InstCombineContributorGuide.html#proofs [17] ——, “Llvm ai tool use policy,” 2026, accessed: 2026-03-23. [Online]. Available: https://llvm.org/docs/AIToolPolicy.html [18] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: agent-computer interfaces enable automated software engineering,” in Proceedings of the 38th International Conference on Neural Information Processing Systems, ser. NIPS ’24, 2024. [19] Y. Chen, “Autoreview: An llm-based multi-agent system for security issue-oriented code review,” in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, ser. FSE Companion ’25, 2025, p. 1022–1024. [Online]. Available: https://doi.org/10.1145/3696630.3728618 [20] F. S. Aðalsteinsson, B. B. Magnússon, M. Milicevic, A. N. Davidsson, and C.-H. Cheng, “Rethinking code review workflows with llm assistance: An empirical study,” in 2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 2025, pp. 488–497. [21] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel, S. Riedel, and D. Kiela, “Retrieval-augmented generation for knowledge-intensive nlp tasks,” in Proceedings of the 34th International Conference on Neural Information Processing Systems, ser. NIPS ’20, 2020. [22] Y. Zhang and K. Leach, “Training large language models to comprehend llvm ir via feedback-driven optimization,” in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, ser. FSE Companion ’25, 2025, p. 1477–1478. [Online]. Available: https://doi.org/10.1145/3696630.3731662 [23] LLVM, “Llvm language reference manual,” 2026, accessed: 2026-03-23. [Online]. Available: https://llvm.org/docs/LangRef.html [24] ——, “Contributing to llvm - how to submit a patch,” 2026, accessed: 2026-06-25. [Online]. Available: https://llvm.org/docs/Contributing. html#how-to-submit-a-patch [25] Y. Zheng, “Llvm ub-aware interpreter,” 2024. [Online]. Available: https://github.com/dtcxzyw/llvm-ub-aware-interpreter [26] GitHub, “Githhub rest api documentation - github docs,” 2026, accessed: 2026-06-25. [Online]. Available: https://docs.github.com/en/ rest?apiVersion=2026-03-10 [27] S. Liu, Y. Chen, R. Krishna, S. Sinha, J. Ganhotra, and R. Jabbarvand, “Process-centric analysis of agentic software systems,” 2026. [Online]. Available: https://arxiv.org/abs/2512.02393 [28] OpenRouter, “Google: Gemini 3.1 pro preview custom tools,” 2026, accessed: 2026-03-29. [Online]. Available: https://openrouter.ai/google/ gemini-3.1-pro-preview-customtools [29] DeepSeek, “Deepseek-v3.2 release,” 2026, accessed: 2026-03-29. [Online]. Available: https://api-docs.deepseek.com/news/news251201 [30] A. C. M. Studio, “Qwen3.5-plus,” 2026, accessed: 2026-0329. [Online]. Available: https://modelstudio.console.alibabacloud. com/ap-southeast-1/?tab=doc#/doc/?type=model&url=2840914_2& modelId=group-qwen3.5-plus [31] I. Tabnam, “Ai code review | greptile,” 2026, accessed: 2026-03-29. [Online]. Available: https://www.greptile.com [32] OpenAI, “Gpt-5.5 | openai,” 2026, accessed: 2026-06-28. [Online]. Available: https://openai.com/index/introducing-gpt-5-5/ [33] Z. Zhou, Z. Ren, G. Gao, and H. Jiang, “An empirical study of optimization bugs in gcc and llvm,” Journal of Systems and Software, vol. 174, p. 110884, 2021. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121220302740 [34] J. Kwon, B. Jang, J. Lee, and K. Heo, “Optimization-directed compiler fuzzing for continuous translation validation,” Proc. ACM Program. Lang., vol. 9, no. PLDI, 2025. [Online]. Available: https://doi.org/10.1145/3729275 [35] S. Dou, M. Zhang, Z. Yin, C. Huang, Y. Shen, J. Wang, J. Chen, Y. Ni, J. Ye, C. Zhang, H. Xie, J. Hu, S. Wang, W. Wang, Y. Xiao, Y. Liu, Z. Xu, Z. Guo, P. Zhou, T. Gui, Z. Wu, X. Qiu, Q. Zhang, X. Huang, Y.-G. Jiang, D. Wang, and S. Yao, “Cl-bench: A benchmark for context learning,” 2026. [Online]. Available: https://arxiv.org/abs/2602.03587 [36] X. Yang, Y. Chen, E. Eide, and J. Regehr, “Finding and understanding bugs in c compilers,” in Proceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI ’11, 2011, p. 283–294. [Online]. Available: https: //doi.org/10.1145/1993498.1993532

[37] C. Lidbury, A. Lascu, N. Chong, and A. F. Donaldson, “Many-core compiler fuzzing,” in Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI ’15, 2015, pp. 65–76. [Online]. Available: https://doi.org/10. 1145/2813885.2737986 [38] R. Morisset, P. Pawan, and F. Zappa Nardelli, “Compiler testing via a theory of sound optimisations in the c11/c++11 memory model,” in Proceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI ’13, 2013, p. 187–196. [Online]. Available: https://doi.org/10.1145/2491956.2491967 [39] V. Livinskii, D. Babokin, and J. Regehr, “Random testing for c and c++ compilers with yarpgen,” Proc. ACM Program. Lang., vol. 4, no. OOPSLA, 2020. [Online]. Available: https://doi.org/10.1145/3428264 [40] ——, “Fuzzing loop optimizations in compilers for c++ and dataparallel languages,” Proc. ACM Program. Lang., vol. 7, no. PLDI, 2023. [Online]. Available: https://doi.org/10.1145/3591295 [41] V. Le, M. Afshari, and Z. Su, “Compiler validation via equivalence modulo inputs,” in Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI’ 14, 2014, pp. 216–226. [Online]. Available: https: //doi.org/10.1145/2666356.2594334 [42] V. Le, C. Sun, and Z. Su, “Finding deep compiler bugs via guided stochastic program mutation,” in Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications, ser. OOPSLA’ 15, 2015, pp. 386–399. [Online]. Available: https://doi.org/10.1145/2858965.2814319 [43] K. Even-Mendoza, A. Sharma, A. F. Donaldson, and C. Cadar, “Grayc: Greybox fuzzing of compilers and analysers for c,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA ’23, 2023, p. 1219–1231. [Online]. Available: https://doi.org/10.1145/3597926.3598130 [44] Y. Chen, T. Su, C. Sun, Z. Su, and J. Zhao, “Coverage-directed differential testing of jvm implementations,” in proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation, ser. PLDI’ 16, 2016, pp. 85–99. [Online]. Available: https://doi.org/10.1145/2980983.2908095 [45] C. Holler, K. Herzig, and A. Zeller, “Fuzzing with code fragments,” in Proceedings of the 21st USENIX Conference on Security Symposium, ser. Security’12, 2012, p. 38. [46] S. Li, T. Theodoridis, and Z. Su, “Boosting compiler testing by injecting real-world code,” Proc. ACM Program. Lang., vol. 8, no. PLDI, 2024. [Online]. Available: https://doi.org/10.1145/3656386 [47] Z. Zhou, B. Limpanukorn, H. J. Kang, J. Wang, Y. Wu, A. Kiss, R. Hodovan, and M. Kim, “Targeted testing of compiler optimizations via grammar-level composition styles,” 2025. [Online]. Available: https://arxiv.org/abs/2512.04344 [48] Z. Xie, M. Wen, S. Qiu, and H. Jin, “Validating jvm compilers via maximizing optimization interactions,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 4, ser. ASPLOS ’24, 2025, p. 345–360. [Online]. Available: https://doi.org/10.1145/3622781.3674188 [49] D. Olewicki, S. Habchi, and B. Adams, “An empirical study on code review activity prediction and its impact in practice,” Proc. ACM Softw. Eng., vol. 1, no. FSE, 2024. [Online]. Available: https://doi.org/10.1145/3660806 [50] R. Wang, J. Guo, C. Gao, G. Fan, C. Y. Chong, and X. Xia, “Can llms replace human evaluators? an empirical study of llm-as-a-judge in software engineering,” Proc. ACM Softw. Eng., vol. 2, no. ISSTA, 2025. [Online]. Available: https://doi.org/10.1145/3728963 [51] R. Tufano, O. Dabić, A. Mastropaolo, M. Ciniselli, and G. Bavota, “Code review automation: Strengths and weaknesses of the state of the art,” IEEE Transactions on Software Engineering, vol. 50, no. 2, pp. 338–353, 2024. [52] X. Tang, K. Kim, Y. Song, C. Lothritz, B. Li, S. Ezzini, H. Tian, J. Klein, and T. F. Bissyandé, “CodeAgent: Autonomous communicative agents for code review,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024, pp. 11 279–11 313. [Online]. Available: https://aclanthology.org/2024.emnlp-main.632/