Understanding Agent-Based Patching of Compiler Missed Optimizations
Abstract: Compiler missed optimizations refer to cases in which compilers failed to optimize certain code. It takes many compiler developers' efforts to implement or patch such missed optimizations. In this paper, we present a systematic study of how well agents patch compiler missed optimizations. We identify a significant challenge that patching a missed optimization requires more than just fixing the reported case, and instead requires generalizing to similar cases. We construct a benchmark of real-world LLVM missed optimization issues and compare agent-generated patches with patches from developers in terms of optimization scope. Our results show that coding agents often optimize the given examples, but many generated patches either cover only part of the developer-intended scope or partially overlap with it; in some cases, they further generalize beyond the reference patch. We further introduce historical-knowledge augmentation techniques that leverage prior LLVM optimization pull requests through retrieval and distillation, showing that they improve developer-aligned generalization and yield practical benefits when applied to real-world IR.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
This paper looks at a problem in compilers (the tools that turn your code into something a computer can run). Compilers try to make your code faster without changing what it does. But sometimes they miss chances to speed things up—these are called “missed optimizations.” The authors ask: can AI coding agents (powered by LLMs) write good patches to fix these missed optimizations, not just for one example, but for many similar cases too?
They study this in LLVM, a popular, real-world compiler framework used by many languages and projects.
What questions did the researchers ask?
The researchers focused on four main questions:
- RQ1: Can AI agents fix real missed-optimization issues, and do their fixes work for the broader set of cases that human developers intended?
- RQ2: If we simply tell the agent “please generalize,” does that make it better at writing broadly useful fixes?
- RQ3: If we give agents helpful history—examples and lessons from past LLVM optimization patches—do they generalize better?
- RQ4: Do these improvements actually help on real programs, not just on small tests?
“Generalize” here means: don’t write a patch that only fixes one specific number or pattern—write a rule that works for all similar situations safely.
How did they study it?
To answer these questions, the authors built a careful test setup and used several ideas. Here’s the approach in everyday terms:
- They built a “benchmark” (a test collection) from 43 real LLVM issues where the compiler missed an optimization. Each issue includes:
- The original example that didn’t get optimized (the “initial test case”).
- The official fix written by LLVM developers (the “golden patch”).
- The tests developers added to prove their fix works (these show the intended scope—what the fix should cover).
- They created an “agent harness,” which is like a safe playground for the AI agent:
- The agent can read relevant LLVM code and docs.
- It can suggest code edits (patches), build LLVM, and run checks.
- Two key checks:
- Alive2 (a tool that checks the patch doesn’t change what the program means).
- llvm-mca (a tool that estimates if the new code could be faster).
- They measured “generalization”—does the agent’s patch match what the human developer intended? They compared two scopes:
- The human developer’s scope (from the golden patch and its tests).
- The agent’s scope (what its patch actually optimizes).
- They categorized results into:
- Agent narrower than the developer (under-generalizes).
- Agent partially overlaps (some right, some wrong).
- Agent matches the developer (good alignment).
- Agent broader (optimizes even more cases, possibly okay if still correct).
- They also “fuzzed” the compilers. Fuzzing means they created lots of slightly different code examples to see if the agent’s patch behaves differently than the developer’s patch. Think of it like giving many practice questions to see where the agent’s rule applies or misapplies.
- They tried two ways to feed history into the agent:
- Retrieval-Augmented Generation (RAG): like looking up similar solved problems from past LLVM patches and showing them to the agent as examples.
- Distillation: like making a cheat sheet of common patterns and lessons (e.g., “don’t forget swapped operands,” “consider equivalent math forms,” “handle all number types”), and giving that to the agent before it writes a patch.
What did they find, and why does it matter?
Here are the main results, explained simply:
- Agents can often fix the one example given in the issue. That’s good.
- But many agent-made patches don’t generalize the way human developers intended. They might:
- Only work for a specific number (like 10) instead of any number.
- Work for some similar cases but miss others.
- Or accidentally apply to cases they shouldn’t.
Example idea: Turning add(max(a, 10), -10) into a “saturating subtract” (subtract 10 but don’t go below zero) is useful. A narrow patch only works for 10. A good patch should work for any constant C: add(max(X, C), -C) → saturating_sub(X, C).
- Simply telling the agent “generalize!” didn’t reliably help. Sometimes it even made things worse—more failures or more under-generalization.
- Giving agents historical knowledge helped:
- With RAG (past examples) and with distilled “cheat sheets,” agents better matched what human developers wanted.
- This led to more patches that covered the right set of cases.
- The improvements also showed benefits on real-world code, not just toy tests.
Why it’s important:
- Compiler developers spend a lot of time adding and adjusting optimization rules.
- If AI agents can propose high-quality, well-generalized patches, it could save time and make programs run faster for everyone.
- The key isn’t just stronger AI—it’s giving AI the right kind of experience and examples.
What methods or technical ideas should a newcomer know?
- Compiler optimization: Like simplifying math expressions to run faster, without changing the answer.
- LLVM IR (Intermediate Representation): A common, low-level “language” inside the compiler where these transformations happen.
- Patch: A small code change to the compiler that adds or improves an optimization rule.
- Generalization: Writing a rule that works for all similar cases, not just one.
- Fuzzing: Generating many random-ish test cases to stress-test behavior.
- Alive2: Tool that checks if an optimization is safe (no change in meaning).
- llvm-mca: Tool that estimates performance on modern CPUs.
- RAG: Letting the agent “look up” similar past fixes to guide its work.
- Distillation: Turning many past fixes into short, reusable principles.
What’s the big takeaway and the possible impact?
- Big takeaway: Fixing missed optimizations isn’t just “make the example pass.” It’s “learn the general rule the developer intended.” Today’s agents need more than a nudge to “generalize”—they need real, practical knowledge from past compiler work.
- Potential impact:
- Better AI-assisted tools for compiler teams.
- Faster software because compilers catch more optimization opportunities.
- A roadmap for other complex engineering tasks: pair AI with a library of high-quality past solutions and distilled guidelines to boost reliability.
In short, the paper shows that AI agents can help with compiler optimizations, but to do it right, they must learn from history—examples and distilled wisdom—not just from the one example in front of them.
Knowledge Gaps
Below is a single, concrete list of the paper’s unresolved knowledge gaps, limitations, and open questions that future work could address:
- Benchmark breadth and representativeness: Only 43 issues, skewed toward InstCombine (32/43), with few cases from other passes (e.g., SimplifyCFG, ValueTracking) and none from backend/Clang/MLIR; unclear generalizability across the broader LLVM ecosystem and other compilers (e.g., GCC, Rustc).
- Approximation of developer intent: Treating the golden patch + tests as a lower bound on intended scope may misrepresent true intent (developers may deliberately restrict scope); no human-in-the-loop adjudication or alternative ground-truth sources (e.g., design notes, code review discussions).
- Golden test extraction heuristic: Assuming the “first test” is the initial case for each PR is brittle; may misidentify the seed vs. additional tests, confounding scope comparisons; no validation of this heuristic’s accuracy.
- Scope classification fidelity: The A ⊂ G, A ⋈ G, G ⊂ A, A ~ G categorization relies on limited golden tests and fuzz samples; lacks formal guarantees and may misclassify subtle under/over-generalizations.
- Fuzzing coverage and power: 1,000 alive-mutate mutants and 60 LLM-generated cases per patch pair may be insufficient; no coverage-guided or constraint-driven fuzzing; no analysis of fuzzing sensitivity to seeds and randomness (lack of repeated runs/statistical variability).
- Correctness checking limits: Alive2 may not fully model all IR features (e.g., poison/undef nuances, intrinsics, flags like nsw/nuw/exact) and could accept/reject transformations incorrectly; no cross-validation with alternative verifiers or backend-level differential testing.
- Profitability and canonicalization proxy: Relying on llvm-mca (block throughput) under a single microarchitecture (x86-64 Skylake) ignores other architectures, code size, latency, register pressure, compile-time cost, and canonicalization conventions; lit failures treated as “soft,” risking acceptance of non-canonical or undesirable transforms.
- Real-world impact (RQ4) underreported: The text claims practical benefits on real-world IR but provides no detailed, multi-arch, multi-project results (e.g., hit rates, runtime speedups, code size changes) or regression analysis on large codebases.
- Interaction with pass pipeline: No study of patch interactions with other passes or pass ordering (e.g., oscillations, missed opportunities, or regressions introduced by new rules).
- Agent harness constraints: Fixed 50-step budget, specific tool choices, and soft handling of lit results may bias outcomes; no ablation on step budget, tool feedback, or different validation pipelines; unclear reproducibility across hardware/software environments.
- Model coverage and variability: Only four LLMs evaluated; no analysis of run-to-run variance, temperature effects, hyperparameters, or statistical significance; results may be sensitive to stochasticity.
- Generic generalization prompting: Only a minimal instruction was tested; no exploration of richer strategies (e.g., few-shot exemplars, plan/spec-first prompting, explicit counterexample-driven refinement, unit-test generation for generalization).
- Historical knowledge retrieval risks: RAG can surface outdated or conflicting patterns; no mechanism to detect contradictions with current codebase or to filter/prioritize examples by recency, component, or coding conventions; no ablation on k, embedding model, or IR normalization for retrieval quality.
- Distillation reliability: Pass-level distilled documents are LLM-synthesized without human vetting or automated consistency checks; risk of hallucinated or oversimplified “rules”; unclear coverage and correctness of distilled knowledge.
- Data leakage concerns: Although benchmark PRs are excluded from the historical corpus, foundation models may have been pretrained on LLVM PRs; contamination could inflate perceived capabilities; no controlled “held-out” evaluation mitigating pretraining exposure.
- Safety and maintainability: No evaluation of code review acceptance, adherence to LLVM style, or long-term maintainability of agent patches; risk that over-generalized rules degrade code quality or future evolvability.
- Beyond peepholes: Focus is on local IR canonicalizations; unclear how the approach scales to larger, control-flow or interprocedural transformations (e.g., loop/vectorization/alias-driven rewrites) where generalization and profitability are more complex.
- Semantics-sensitive edge cases: Limited exploration of tricky cases involving poison/undef propagation, flags (nsw/nuw/exact), fast-math, and value-tracking assumptions; need targeted benchmarks and analyses for these pitfalls.
- Update lifecycle for historical knowledge: No mechanism to keep retrieved/distilled knowledge current with evolving LLVM design decisions; risk of perpetuating deprecated idioms.
- Legal/ethical aspects of reuse: Potential for code “cargo-culting” or near-duplication from historical patches; unclear handling of licensing and originality in generated patches.
- Missing ablations: No detailed ablations to attribute gains to specific augmentation elements (e.g., examples vs. summaries, retrieval diversity, document length) or to disentangle the contributions of Alive2/mca/lit in agent decision-making.
- Qualitative failure taxonomy: Limited qualitative analysis of why agents under-/over-generalize (e.g., pattern matching errors, misread semantics, profit misestimation); absence of a diagnostic taxonomy to guide future agent design.
- Formalizing intent: Open question on representing developer intent as machine-checkable specifications (e.g., canonicalization policies, rewrite systems with side conditions) to move beyond proxy-based evaluation.
- Solver–agent co-design: Open question on integrating theorem provers/superoptimizers (e.g., Alive, Souper/Hydra) with LLM agents to propose rules that are both proven correct and guided by learned profitability/generalization priors.
- Evaluation metrics: Need richer measures beyond pass/fail counts—e.g., degree of over/under-generalization, precision/recall against an enumerated sandbox, or cost-benefit curves under multi-arch constraints.
- Cross-project generalization: Unclear whether the methods transfer to other compiler infrastructures (GCC, MLIR, Rustc) or different IRs; external validity remains an open question.
Practical Applications
Immediate Applications
The paper delivers a practical, evaluated workflow for using LLM agents to patch compiler missed optimizations and shows that historical-knowledge augmentation (retrieval and distilled pass-level rules) improves alignment with developer intent. The following are deployable now with reasonable engineering effort.
- Software/DevTools: “Missed-Optimization Triage Bot” for LLVM-like projects
- Use case: A GitHub/GitLab bot that ingests issue test cases, retrieves similar past PRs (RAG), and proposes scoped patches with Alive2 correctness checks and llvm-mca cost checks.
- Tools/workflow: RAG over PR-based source–target IR pairs; distilled pass-level guidance; agent harness (ReAct loop) with apply_code, build_and_check, lit_check; Alive2; llvm-mca.
- Dependencies/assumptions: Availability of high-quality LLM, historical PR data; CI capacity to run Alive2/llvm-mca; maintainer approval workflow; limited to components with robust tests (e.g., InstCombine).
- Software/Infrastructure: CI “Missed Optimization” gate for performance regressions
- Use case: CI step that runs llvm-mca on hot functions and flags code shapes known to be suboptimal; provides links to analogous past fixes and patch suggestions.
- Tools/workflow: Distilled pass-level rules as linting checks; IR extraction from builds; llvm-mca throughput thresholds; Alive2 when proposing transforms.
- Dependencies/assumptions: Stable microarchitecture models; IR extraction tooling; baseline cost policies per target; tolerance for some false positives.
- Software/Compiler Teams: Reviewer co-pilot for optimization-scope alignment
- Use case: During code review, the system compares a candidate optimization against retrieved historical patterns and runs fuzz-based scope-diff to highlight under- or over-generalization.
- Tools/workflow: RAG; LLM-based IR test generator and alive-mutate; A/B runs on agent- vs golden-patched compilers; Alive2 + llvm-mca triage.
- Dependencies/assumptions: Compute/time budget for fuzzing; existing or provisional “golden” reference; internal code review integration.
- Academia/Research: Benchmark for generalization-sensitive patching
- Use case: Evaluate LLMs and agent frameworks on a curated, real-world LLVM missed-optimization benchmark with scope-aware metrics.
- Tools/workflow: The paper’s 43-instance benchmark; golden tests; fuzz-based scope assessment; structured categories (A⊂G, A⋈G, G⊂A, A∼G).
- Dependencies/assumptions: Reproducible LLVM builds at specific commits; access to Alive2 and llvm-mca; consistent hardware targets for performance modeling.
- Academia/Teaching: Course modules/labs on optimization generalization
- Use case: Hands-on labs where students implement generalized transforms, use fuzzing to test scope, and observe the effect of RAG/distillation.
- Tools/workflow: Provided harness; curated PR knowledge base; small-scale IR fuzzing exercises; scope relationship analysis.
- Dependencies/assumptions: Lab machines with LLVM toolchain; controlled seed benchmarks; instructor guidance on formal equivalence limits.
- Hardware/ISVs: Onboarding guidance for new ISA features in middle-end passes
- Use case: Encode recurring generalization patterns (e.g., saturation, min/max families) in distilled documents to reduce missed optimizations when new instructions land.
- Tools/workflow: Pass-level distilled knowledge; PR retrieval of similar instruction introductions; Alive2 specs for new intrinsics.
- Dependencies/assumptions: Spec availability and formal models for new intrinsics; timely distillation updates; coordination across back-end and middle-end.
- OSS Governance/Policy-in-Practice: Contribution checklist for AI-generated compiler patches
- Use case: Require evidence bundles (golden-test pass, fuzz scope-diff results, Alive2 proofs, llvm-mca wins) in PR templates for AI-authored patches.
- Tools/workflow: CI templates; automated artifact attachment (logs, IR diffs); maintained RAG index for traceability.
- Dependencies/assumptions: Maintainer buy-in; structured PR metadata; security policies for LLM usage.
- Developer Productivity (Daily life for systems engineers): IDE extension for optimization hints
- Use case: In-editor “Why wasn’t this optimized?” quick-fix that shows the missing pattern, similar past fixes, and suggested rewrite guarded by Alive2.
- Tools/workflow: Source-to-IR mapping; small local IR builder; cloud-side retrieval and analysis; patch preview.
- Dependencies/assumptions: Compiler debug info; privacy constraints for code upload; compute latency budget.
Long-Term Applications
The study points to broader, system-level opportunities once reliability, scalability, and governance mature. These require further research, scaling, or multi-org coordination.
- Software/Compilers: Self-updating optimization agent with guardrails
- Use case: A continuous system that monitors issues, synthesizes generalized patches, validates via formal tools and fuzzing, and auto-opens PRs with scope evidence.
- Tools/workflow: Persistent RAG index across repos; pass-level distilled corpora that self-refresh; reinforcement via PR outcomes; stronger formal coverage than Alive2 where needed.
- Dependencies/assumptions: Robust trust and review pipelines; better semantics coverage (UB, poison, fast-math); cost models across architectures; governance for auto-proposed changes.
- Cross-ecosystem Transfer: GCC/MLIR/Rustc knowledge transfer
- Use case: Port distilled generalization principles and IR-pattern examples to other compilers and IRs; enable shared knowledge hubs.
- Tools/workflow: IR-agnostic canonicalization schemas; cross-IR retrieval adapters; common formal equivalence frameworks.
- Dependencies/assumptions: Mapping between IR semantics; community collaboration; licensing compatibility.
- Domain-Specific Languages & HPC: Auto-generalizing optimization for DSL compilers
- Use case: Integrate agents to learn and generalize transforms for DSLs (e.g., tensor, image, query languages) guided by domain-specific cost models.
- Tools/workflow: Domain cost simulators; operator algebra rules; retrieval over DSL PRs and kernels; test synthesis for numerical stability.
- Dependencies/assumptions: High-fidelity cost/accuracy models; numerical soundness constraints; representative corpora.
- Cloud/Finance/Healthcare/Robotics/Energy: Fleet-scale performance and cost optimization
- Use case: Apply agent-guided, verified transforms to performance-critical services (trading engines, EHR analytics, path planners, edge IoT) to reduce latency/CPU/energy.
- Tools/workflow: Service-level IR extraction; SLO-aware cost functions (latency, energy); canary deploys; automated rollback on regressions.
- Dependencies/assumptions: Strong observability and rollback; safety constraints (e.g., medical/financial compliance); heterogeneity of hardware.
- Security & Safety: Side-channel- and constant-time-aware optimization generalization
- Use case: Agents that internalize rules to avoid unsafe generalizations in cryptographic or safety-critical code; auto-detects when optimizations violate CT/security constraints.
- Tools/workflow: Extended distillation with security patterns (CT, speculative safety); formal side-channel analyses; policy flags in IR.
- Dependencies/assumptions: Formalized security annotations in IR; availability of analyses; conservative defaults.
- Energy-Aware Compilation: Carbon- and battery-optimized generalization
- Use case: Incorporate energy/perf trade-offs in the agent’s decision loop to produce transforms that lower power on mobile/edge and data-center workloads.
- Tools/workflow: Power models (uArch, DVFS); telemetry-guided cost functions; retrieval of energy-saving patterns.
- Dependencies/assumptions: Accurate, portable energy models; per-target calibration; acceptance of performance–energy trade-offs.
- Formal Methods Advancement: Broader equivalence checking and semantics coverage
- Use case: Extend beyond Alive2 capabilities to cover more IR constructs and floating-point subtleties, enabling broader automated patch spaces.
- Tools/workflow: New SMT- and proof-assisted equivalence frameworks; integration into agent loops; counterexample-guided refinement.
- Dependencies/assumptions: Research breakthroughs in semantics modeling; solver scalability; floating-point and UB precision.
- Workforce & Education Policy: Curriculum and training standards for AI-assisted compiler engineering
- Use case: Standardize competencies (scope generalization, fuzzing, equivalence, cost modeling) and certify safe AI tooling use in critical infrastructure software.
- Tools/workflow: Shared benchmarks and leaderboards; open courseware; industry–academia partnerships.
- Dependencies/assumptions: Community consensus; sustained funding; alignment with professional accreditation bodies.
- Commercial Products: SaaS “Compiler Knowledge Base + Patch Assistant”
- Use case: Vendor offering retrieval-backed optimization insights, internal PR indexing, compliance/audit trails for AI-generated changes.
- Tools/workflow: Private RAG indexes; on-prem or VPC deployments; policy engines; cost dashboards.
- Dependencies/assumptions: Data governance for proprietary code; integration with customer CI/CD; SLAs on latency and correctness.
- Autotuning at the IR Level: Continuous per-repo specialization
- Use case: Agents propose safe micro-optimizations tailored to real profile data, generalizing patterns across codebases and versions.
- Tools/workflow: Profile-guided IR extraction; multi-variant exploration; safe guards with formal checks; rollout via feature flags.
- Dependencies/assumptions: High-quality profiles; low-variance performance measurements; robust A/B infrastructure.
These applications leverage the paper’s core insights: (1) success in missed-optimization patching hinges on correctly inferring and implementing the intended generalization scope, (2) generic “be more general” prompts are insufficient, and (3) historical-knowledge augmentation (RAG over prior IR transforms and distilled pass-level principles) meaningfully improves alignment, making agent outputs more practically useful and trustworthy.
Glossary
- alive-mutate: A tool that generates mutated LLVM IR programs to fuzz compilers for behavioral differences. "For the fuzzing component, we use alive-mutate~\cite{fan2024high} as the traditional fuzzer."
- Alive2: A formal verifier for checking semantic correctness of LLVM IR transformations. "Validation checks correctness with Alive2~\cite{lopes2021alive2} and estimates effectiveness with llvm-mca~\cite{llvm_mca_doc} using block-throughput cost."
- Agent harness: A controlled environment and tool interface that enables an agent to implement and validate compiler patches. "we implement a lightweight agent harness for LLVM missed-optimization issues."
- Block-throughput cost: A performance metric from llvm-mca estimating instruction throughput for basic blocks. "using block-throughput cost."
- Canonicalization: The process of rewriting IR into a standard form to enable consistent optimization. "local IR canonicalization and peephole simplification"
- ConstraintElimination: An LLVM optimization component that removes redundant constraints or conditions. "The remaining cases involve SimplifyCFG, ValueTracking, ConstraintElimination, and InstructionSimplify."
- Distillation: Summarizing recurrent optimization patterns and principles into compact, reusable knowledge. "and distillation, which summarizes recurring component-level generalization principles as compact background knowledge."
- FileCheck: An LLVM testing tool that matches expected textual patterns in compiler outputs. "because FileCheck patterns can be sensitive to non-semantic textual differences."
- Fuzzing: Generating randomized or guided inputs to explore optimization behavior and find divergences. "We use two complementary fuzzing strategies."
- Golden patch: The developer-submitted fix that approximates the intended optimization behavior for an issue. "The golden patch is the developer's fix, and its scope ."
- Golden test cases: The developer-added or modified tests that exemplify the intended optimization scope. "These golden test cases serve as observable samples of the intended optimization scope and provide a lower-bound approximation."
- Intermediate Representation (IR): A compiler’s internal program representation used for analysis and optimization. "They first observe that a particular intermediate representation (IR) fragment admits a more optimized form,"
- InstCombine: LLVM’s central pass for local IR canonicalization and peephole optimizations. "InstCombine accounts for the majority of cases because it is LLVM's central pass for local IR canonicalization and peephole simplification, where many missed optimizations are reported and fixed."
- InstructionSimplify: An LLVM component that simplifies instructions leveraging semantic reasoning. "The remaining cases involve SimplifyCFG, ValueTracking, ConstraintElimination, and InstructionSimplify."
- LLVM IR: The specific intermediate representation language used by LLVM. "Each patch induces a partial transformation over LLVM IR programs."
- LLVM Language Reference Manual (LangRef): Official documentation of LLVM IR semantics and constructs. "and LLVM Language Reference Manual~\cite{llvm-langref},"
- lit: LLVM’s test runner for executing and validating test suites. "We also run lit~\cite{llvm-lit-doc} to detect regressions,"
- llvm-mca: A performance analysis tool that models microarchitectural throughput for LLVM-generated code. "and then check the efficiency of the optimized IR using llvm-mca."
- Missed optimization: A situation where the compiler preserves semantics but fails to generate a more efficient form. "A missed optimization occurs when a compiler preserves program semantics but fails to produce a more efficient form."
- Optimization pass: A compiler module that applies a specific class of transformations to improve code. "we first record the optimization pass to which the missed optimization belongs."
- Optimization scope: The set of programs for which a transformation applies while preserving semantics. "The optimization scope is the set of programs on which applies and preserves semantics:"
- Peephole simplification: Small-scale local rewrites that replace inefficient instruction sequences with simpler ones. "local IR canonicalization and peephole simplification"
- ReAct loop: An agent strategy that interleaves reasoning steps with tool actions to iteratively solve tasks. "The agent then enters a ReAct loop~\cite{yao2022react} that interleaves root-cause analysis, source inspection, patch synthesis, and validation."
- Regression test: A test that ensures fixes remain effective and do not introduce new issues. "and confirm that the regression test passes with the expected optimized output."
- Retrieval-Augmented Generation (RAG): A method that augments model generation with retrieved, relevant examples or documents. "retrieval-augmented generation (RAG)~\cite{lewis2020retrieval}, which provides similar source-to-target IR transformations as concrete precedents,"
- SimplifyCFG: An LLVM pass that simplifies control-flow graphs by removing redundancies and normalizing structures. "The remaining cases involve SimplifyCFG, ValueTracking, ConstraintElimination, and InstructionSimplify."
- Souper: A superoptimizer for LLVM that searches for equivalent but more efficient code transformations. "including superoptimizers represented by Souper~\cite{sasnauskas2017souper},"
- Superoptimizer: A tool that exhaustively searches for optimal rewrites across instruction patterns. "including superoptimizers represented by Souper"
- usub.sat: An LLVM operation for saturated unsigned subtraction (clamps results at 0 on underflow). "\mathtt{usub.sat}(X, C)."
- ValueTracking: An LLVM analysis that infers properties of values to enable simplifications and optimizations. "The remaining cases involve SimplifyCFG, ValueTracking, ConstraintElimination, and InstructionSimplify."
- WhiteFox: An LLM-driven system that guides test generation to expose behavioral differences in compiler transformations. "Inspired by WhiteFox~\cite{yang2024whitefox},"
Collections
Sign up for free to add this paper to one or more collections.