Pith. sign in

REVIEW 4 major objections 5 minor 31 references

Treating LLM kernel optimization as progressive cross-layer diagnosis yields 4.35x NPU kernel speedups.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 03:36 UTC pith:EELPGRD6

load-bearing objection Real architecture, honest evaluation, but the 4.35× speedup is not yet attributable to the compiler-grounding loop — the paper admits the missing temporal control in §8. the 4 major comments →

arxiv 2607.23089 v1 pith:EELPGRD6 submitted 2026-07-25 cs.AI cs.PL

Compiler-Grounded Hierarchical Diagnosis for LLM-Based Triton Kernel Optimization

Dongjie Chen , Ping Zhao , Bohua Zhan , Yulong Wang , Shushu Chen , Liangjun Feng , Hao Zhou , Min Shen
show 6 more authors
Linmu Wang Weijia Sheng Xiangyu Wei Weijie Ding Jianhui Huang Yaoqing Gao
This is my paper
classification cs.AI cs.PL
keywords LLM-based kernel optimizationTritoncompiler groundinghierarchical diagnosisIR attributionNPUprogram optimizationperformance engineering
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that LLM-driven kernel optimization should be framed as progressive cross-layer diagnosis rather than source-level trial and error: start with cheap pattern triage, move to profiling, and escalate to IR attribution and compiler-grounded analysis only when shallow evidence cannot justify a rewrite. On a 37-operator NPU benchmark, the resulting system reports a geometric-mean 4.35x and median 2.73x speedup from initial to optimized Triton kernels, with 22 of 37 operators at least doubling. If the result holds, it shows that explaining why a backend compiler fails to optimize — not just that a kernel is slow — is what lets an LLM agent produce rewrites that survive correctness validation on proprietary NPU stacks. The paper is careful to present this as a systems argument with process evidence, not a causal ablation of the hierarchy.

Core claim

The central claim is that many performance failures on NPUs are only visible after lowering, so an optimizer that reads only source and runtime timings cannot distinguish, say, a scalar-heavy path caused by source control flow versus one caused by an IR lowering decision. The paper demonstrates a four-level workflow — pattern triage, profiling diagnosis, IR attribution, compiler-source escalation — that attaches each rewrite to evidence at the deepest level required, and shows that this workflow, run by a general-purpose coding agent, produces retained optimized kernels whose geometric-mean speedup over five sampled cases per operator is 4.35x (median 2.73x), with a long tail from near-basel

What carries the argument

The carrying mechanism is the escalation ladder with explicit round states: a validated baseline state, per-round hypothesis/evidence records, three concrete escalation tests (a dominant hotspot is identified, exactly one rewrite family is justified, and the evidence at the current level suffices), and an auditable round contract enforced by a thin harness. A retrospective synthesis pass rereads validated optimization histories and refreshes the cheapest layer, pattern triage, so the low-cost layer improves across batches rather than staying fixed.

Load-bearing premise

The speedup evidence stands only if the 37 successfully converted operators with five sampled cases each form a fair, fixed benchmark and if the retrospective pattern-synthesis loop is not substantially memorizing the same batch it is evaluated on; the paper reports neither a temporal split between history learning and evaluation nor repeated-run error bars.

What would settle it

Run the same 37-operator, 185-case cohort under one frozen toolchain with three policies — profiling-only, full hierarchy, and always-deep — and compare geometric-mean speedups; if profiling-only matches 4.35x, the compiler-grounded layers are not the driver. For the retrospective loop, rebuild the pattern index only from earlier benchmark batches and evaluate on held-out later batches; if speedups persist without same-batch synthesis, the loop's contribution is real rather than memorization.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If correct, profiling-only agents are structurally limited: they can localize a hotspot but cannot decide among competing rewrites whose difference only appears after lowering, so compiler-grounding is necessary for a class of backend-specific speedups.
  • A concrete corollary demonstrated in the paper: an algebraic rewrite that avoids index-producing reductions (replacing argmax-and-mask with maximum off-diagonal pair sum) can remove synchronization operations that profiling alone could not attribute.
  • The distribution result implies headroom is real but uneven: 22/37 entries exceed 2x and 13/37 exceed 5x while some remain near baseline, so the method targets kernels with backend-specific pathologies rather than being a universal accelerator.
  • Process accounting shows the cheapest level can be the winning level (33/37 best rounds at pattern triage) even when deeper levels were exercised earlier in the same trajectory, so the hierarchy's value is often diagnosis and rejection rather than direct discovery of the final rewrite.
  • Many entries (22/37) first reach their best validated result after round 8, indicating that late rounds carry real optimization value under a 15-round budget.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: if the retrospective synthesis loop benefits from late-round evidence, the five-cases-per-operator protocol understates its value because the loop is evaluated on the same batch it synthesizes from; a held-out batch design would be a cleaner test.
  • Editorial inference: the escalation principle should transfer to other accelerator backends in proportion to how much pass-level evidence their IR toolchains expose; on backends with opaque lowering, the hierarchy collapses toward profiling-only search.
  • Editorial inference: the late-peaking best-round indices suggest the 15-round cap truncates some trajectories, so a round-budget sweep would expose the marginal value curve of the hierarchy more sharply than the single fixed budget does.
  • Editorial inference: the single strongest testable extension is a frozen-toolchain ablation comparing the hierarchy against profiling-only and always-deep policies; the paper explicitly defers this, so the headline speedup should be read as an existence proof of the workflow, not a measurement of the compiler-grounding component's marginal contribution.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces a compiler-grounded hierarchical diagnosis framework for LLM-based Triton kernel optimization. The workflow escalates across four evidence levels — pattern triage, profiling diagnosis, IR attribution, and compiler-source escalation — and includes a retrospective synthesis pass that refines the pattern index after batched optimization runs. The implementation is evaluated on an NPUKernelBench-derived Ascend 950 suite: after removing failed Torch-to-Triton conversions, 37 operators remain, each optimized for 15 rounds with five sampled benchmark cases. The headline result is a geometric-mean speedup of 4.35x and a median of 2.73x from initial to optimized Triton kernel, with 22/37 entries exceeding 2x and 13/37 exceeding 5x. The paper also reports round-level accounting (best-round index, evidence levels reached) and a representative cross-layer trace. The authors are explicit that the evaluation does not causally isolate the contribution of the hierarchy or the retrospective synthesis loop (§8).

Significance. The potential contribution is significant for the LLM-for-systems community: it demonstrates large measured speedups on a proprietary NPU stack and offers a concrete architecture for turning compiler-level evidence into agent decisions. The paper's strengths include direct runtime measurements rather than derived reward proxies, full disclosure of the speedup distribution, an auditable round-state design, and an unusually candid limitations section. The main weakness is that the central number is not yet interpretable because the initial baseline kernels are unspecified, the pattern index may have been refreshed on the same benchmark, and no measurement variance is reported. If these issues are resolved with additional data, the result would be a credible systems contribution; as it stands, the paper supports a 'systems argument' only under strong assumptions that the authors themselves identify as uncontrolled.

major comments (4)
  1. [§4.1, §8] Table 1's 4.35x geometric-mean speedup is claimed for 'the system', but the system's L1 pattern triage is not a fixed component: §4.1 states that 'after batched benchmark optimization runs finish, the system performs a retrospective synthesis pass over the per-round optimization trajectories' and that 'future optimization sessions therefore start from a refreshed low-cost hypothesis layer.' The paper never states whether the reported 37-entry batch was the first batch on this NPUKernelBench-derived suite or a later batch whose pattern index already contained histories distilled from the same benchmark operators. If the latter, the speedup can be partially explained by memorized pattern families for exactly the operators being evaluated, not by the online diagnostic loop. This is not merely a missing ablation — it makes the headline measurement uninterpretable. Please report whether the p
  2. [§6.1] The speedup is 'initial-to-optimized Triton kernel', but §6.1 never specifies how the initial Triton implementations were obtained or how much effort had already been spent on them. It only says 'a Triton implementation whose baseline is validated.' If these are vendor-provided or benchmark-reference kernels, the absolute speedup may be informative; if they are randomly generated or deliberately unoptimized, the 4.35x is inflated. Please document the origin of the initial kernels, list their tile sizes/autotuning choices, and show at least one complete before/after pair in the appendix. Without this, Table 1 cannot be independently assessed.
  3. [§6.1, Figure 4] All speedups are computed from single aggregate geometric means; no repeated-run variance, confidence intervals, or trial counts are reported for the kernel times in Figure 4. On shared or clock-variable NPU hardware, runtime measurements are noisy. The claim that these are 'direct runtime measurements' does not by itself establish stability. Please report the number of runs per case, the selection rule (e.g., min/median), and per-operator confidence intervals, or at least a repeat-measurement study for a subset of operators.
  4. [§6.1] The cohort is defined as the 37 operators that survived 'removing failed Torch-to-Triton conversions', but no denominator, failure list, or failure criteria are reported. If conversion failures correlate with operator shape or backend quirks, the reported speedup distribution is conditional on an unmodeled selection event. Please report the total number of operators in the original NPUKernelBench-derived suite, the conversion success rate, the reasons for failure, and whether the retained cohort is representative of the full suite. Also specify the random sampling protocol used to choose the five cases per operator.
minor comments (5)
  1. [§6.1, Tables 1–2] The Level 1/Level 2 grouping used in Tables 1 and 2 is never defined. This is not just notation; it is necessary for interpreting the level-wise comparisons and the claim that 'the two benchmark groups contain different operators and shapes.'
  2. [§2.1, §6.1] The running example states that the rewrite 'passes all 50 correctness cases,' while §6.1 uses five benchmark cases per operator. Clarify the relationship between the correctness set and the optimization benchmark set.
  3. [Abstract, §1, §4] The paper uses lowercase 'the system' at the beginning of sentences (e.g., Abstract: 'the system escalates'; §1: 'the system forms'). Please fix capitalization throughout.
  4. [§5, §6.5] Backend-specific terms such as AIV/AIC, hivmave, and brc_scalar_core_1d are used without definition. A short glossary or first-use parenthetical would help readers outside the Ascend ecosystem.
  5. [References] The NPUKernelBench reference points to a branch URL (br_430/benchmarks/NPUKernelBench) rather than a stable release or DOI. Similarly, the CannBot skills repository link has no version/commit. Please cite stable snapshots.

Circularity Check

1 steps flagged

Headline speedup partly conflates retrospective pattern-index fitting with the online diagnostic loop; no derivational circularity.

specific steps
  1. fitted input called prediction [§4.1 (Retrospective synthesis) / §6.1 (Fixed benchmark) / §8 (Limitations)]
    "After batched benchmark optimization runs finish, the system performs a retrospective synthesis pass over the per-round optimization trajectories. ... The result is a refreshed quick-match index for future sessions: pattern triage starts from accumulated cross-operator evidence rather than from isolated one-off successes."

    The L1 pattern index is fitted to validated optimization histories, and the reported speedups are measured on the same NPUKernelBench-derived cohort ('37 successfully converted Triton operators', 'fixed benchmark used throughout optimization'). The paper never states that the pattern index was frozen before this cohort or that the synthesis pass excluded the cohort's own histories. Section 8 admits it 'does not separate the effect of the retrospective pattern-synthesis loop from the seeded pattern guidance.' Thus, for later entries, the initial pattern triage can contain near-solutions learned from earlier entries in the same benchmark, so a portion of the 4.35x/2.73x speedup is recall from the fitting set rather than independent evidence of the online diagnostic hierarchy. This is in-benc

full rationale

The paper contains no derivational circularity: no quantity is defined in terms of the target speedup, no equations reduce to one another, and there are no author self-citations used as load-bearing evidence. The speedups are measured runtimes from a real benchmark. The one circularity-adjacent defect is the retrospective pattern-synthesis loop: L1 pattern guidance is updated from validated optimization histories (§4.1), while the evaluation cohort is the same NPUKernelBench-derived suite (§6.1), and §8 explicitly says the effect of this loop is not separated from the seeded guidance. Without a temporal or frozen-index control, the headline speedup is open to in-benchmark leakage, so the central empirical claim is partially self-referential. Because the derivation chain itself is not equivalent to its inputs, this warrants 4 rather than 6+.

Axiom & Free-Parameter Ledger

2 free parameters · 5 axioms · 0 invented entities

The central claim depends on a standard algebraic identity and on several unverified evaluation assumptions: cohort representativeness, trustworthiness of IR/compiler records, measurement stability, and non-contamination of the pattern index. No new physical or mathematical entities are introduced.

free parameters (2)
  • Optimization round budget = 15 rounds per operator
    Hand-chosen budget; the median best validated round index is 10 and 12 entries peak in the final three rounds, so results depend on this arbitrary budget.
  • Benchmark cases per operator = 5 sampled cases
    Five cases sampled from each operator's original benchmark inputs; no sensitivity analysis is reported, and the headline geometric-mean speedup is a function of this sample.
axioms (5)
  • standard math max_{i != j}(v_i + v_j) equals the sum of the two largest group values, including tied maxima.
    Used to justify the MoE group-score rewrite in §2.1; true under ordinary arithmetic.
  • domain assumption The 37 successfully converted NPUKernelBench-derived entries with five sampled cases per operator are representative of Triton kernel optimization on Ascend 950.
    The cohort excludes failed Torch-to-Triton conversions; failure rates and the selection mechanism are not quantified. Stated in §6.1.
  • domain assumption IR dumps and agent-recorded pass names such as 'hivmave-scalar-broadcast-to-vload' and 'brc_scalar_core_1d' faithfully capture the compiler mechanism and are stable enough to support attribution.
    No compiler source, pass definitions, or dump artifacts are shipped; these records underpin the L3/L4 claims in §6.5.
  • domain assumption Kernel-time geometric mean over five cases is a stable performance measure without repeated-run variance.
    No error bars or confidence intervals are reported in §6.1 or Figure 4.
  • ad hoc to paper Retrospective synthesis updating the pattern index does not leak information from the evaluated benchmark batch into later entries.
    The paper describes pattern triage being refreshed from validated histories (§4.1) but never demonstrates a temporal or cross-validation split separating those histories from the 37 entries being scored.

pith-pipeline@v1.3.0-alltime-deepseek · 12585 in / 12266 out tokens · 128199 ms · 2026-08-01T03:36:44.459567+00:00 · methodology

0 comments
read the original abstract

Recent advances in large language models (LLMs) have enabled automated kernel generation and optimization, but most existing approaches rely on surface signals such as compilation feedback and profiling metrics. These signals reveal that a kernel is slow, but not why the backend compiler fails to realize a profitable optimization, especially on emerging accelerators such as NPUs. We therefore formulate kernel optimization as a progressive cross-layer diagnosis problem that links runtime symptoms to IR structure and compiler behavior before rewriting source. Based on this insight, we present our system, a compiler-grounded and hierarchical optimization framework for Triton kernels. the system escalates from lightweight pattern triage and profiling diagnosis to IR attribution and compiler-grounded analysis only when deeper evidence is needed, then proposes evidence-backed source-level rewrites. We implement the system on Triton for Ascend NPUs and evaluate it on 37 successfully converted entries from a standardized NPUKernelBench-derived Ascend 950 benchmark. Across these entries, the system attains a geometric-mean speedup of 4.35$\times$ and a median speedup of 2.73$\times$ from the initial to optimized Triton kernel; 22/37 exceed 2$\times$ and 13/37 exceed 5$\times$. The complete distribution ranges from near-baseline entries to large wins, motivating transparent reporting of the current system's scope and limitations.

Figures

Figures reproduced from arXiv: 2607.23089 by Bohua Zhan, Dongjie Chen, Hao Zhou, Jianhui Huang, Liangjun Feng, Linmu Wang, Min Shen, Ping Zhao, Shushu Chen, Weijia Sheng, Weijie Ding, Xiangyu Wei, Yaoqing Gao, Yulong Wang.

Figure 1
Figure 1. Figure 1: Actual source rewrite for the MoE group-score kernel. The maximum off-diagonal pair sum is mathematically equal to the sum of the two largest group values, so the rewrite removes index-producing reduction while preserving ties. IR attribution then identifies 26 synchronization operations in the early lowered stages and ties them to the argmax reductions and index-mask construction. Compiler-source analysis… view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the system. The loop escalates from pattern triage to profiling, IR attribution, and compiler-grounded analysis only when lower-cost evidence is insufficient, then proposes evidence-backed source-level rewrites. only the one or two detailed pattern references that match the current symptom. The corresponding pattern guidance mixes publicly documented Triton idioms, including autotuning, program… view at source ↗
Figure 3
Figure 3. Figure 3: Distribution of Triton kernel optimization speedups, ordered by speedup. Level 1 Level 2 Overall 50 100 150 142.57 17.72 51.70 Speedup L1/L2/All: 7.29× / 2.51× / 4.35× 19.54 7.05 11.9 Kernel time (geometric mean, 𝜇s) initial optimized [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Geometric-mean Triton kernel time before and after opti￾mization [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Optimization accounting. Panel (a) records the round with the best validated, comparable per-round result; panel (b) records the primary evidence level of that selected round; panel (c) records whether the complete trajectory reaches each level at least once. Thus, panel (b) does not measure whether deeper analysis was used before the selected round. The median best-round index is 10; 28/37 winning-round l… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 7 linked inside Pith

  1. [1]

    Triton Ascend Ops

    Ascend. Triton Ascend Ops. GitHub repository, 2026. https://github.com/Ascend/triton-ascend-ops

    2026

  2. [2]

    Kevin: Multi-turn RL for generating CUDA kernels, 2025

    Carlo Baronio, Pietro Marsella, Ben Pan, Simon Guo, and Silas Alberti. Kevin: Multi-turn RL for generating CUDA kernels, 2025. arXiv preprint arXiv:2507.11948

    Pith/arXiv arXiv 2025

  3. [3]

    AscendKernelGen: A systematic study of LLM-based kernel generation for neural processing units, 2026

    Xinzi Cao, Jianyang Zhai, Pengfei Li, Zhiheng Hu, Cen Yan, Bingxu Mu, Guanghuan Fang, Bin She, Jiayu Li, Yihan Su, Dongyang Tao, Xiansong Huang, Fan Xu, Feidiao Yang, Yao Lu, Chang-Dong Wang, Yutong Lu, Weicheng Xue, Bin Zhou, and Yonghong Tian. AscendKernelGen: A systematic study of LLM-based kernel generation for neural processing units, 2026. arXiv pre...

    Pith/arXiv arXiv 2026

  4. [4]

    AVO: Agentic variation operators for autonomous evolutionary search,

    Terry Chen, Zhifan Ye, Bing Xu, Zihao Ye, Timmy Liu, Ali Hassani, Tianqi Chen, Andrew Kerr, Haicheng Wu, Yang Xu, Yu-Jung Chen, Hanfeng Chen, Aditya Kane, Ronny Krashinsky, Ming-Yu Liu, Vinod Grover, Luis Ceze, Roger Bringmann, John Tran, Wei Liu, Fung Xie, Michael Lightstone, and Humphrey Shi. AVO: Agentic variation operators for autonomous evolutionary search,

  5. [5]

    TVM: An automated end-to-end optimizing compiler for deep learning

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. TVM: An automated end-to-end optimizing compiler for deep learning. In13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 578–594, 2018

    2018

  6. [6]

    DeepSeek-V4: Towards highly efficient million-token context intelligence, 2026

    DeepSeek-AI. DeepSeek-V4: Towards highly efficient million-token context intelligence, 2026

    2026

  7. [7]

    Awesome LLM-driven kernel generation

    flagos-ai. Awesome LLM-driven kernel generation. GitHub repository, 2026. https://github.com/flagos-ai/ awesome-LLM-driven-kernel-generation

    2026

  8. [8]

    KPerfIR: Towards an open and compiler-centric ecosystemforGPUkernelperformancetoolingonmodern AI workloads

    Yue Guan, Yuanwei Fang, Keren Zhou, Corbin Robeck, Manman Ren, Zhongkai Yu, Yufei Ding, and Adnan Aziz. KPerfIR: Towards an open and compiler-centric ecosystemforGPUkernelperformancetoolingonmodern AI workloads. In20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25), 2025

    2025

  9. [9]

    NPUKernelBench

    Just-it. NPUKernelBench. GitHub repository, 2026. https://github.com/Just-it/AscendOpGenAgent/ tree/br_430/benchmarks/NPUKernelBench

    2026

  10. [10]

    PRAGMA: A profiling-reasoned multi-agent framework for automatic kernel optimization, 2025

    Kelun Lei, Hailong Yang, Huaitao Zhang, Xin You, Kaige Zhang, Zhongzhi Luan, Yi Liu, and Depei Qian. PRAGMA: A profiling-reasoned multi-agent framework for automatic kernel optimization, 2025. arXiv preprint arXiv:2511.06345

    arXiv 2025

  11. [11]

    TritonForge: Profiling-guided framework for automated Triton kernel optimization, 2025

    Haonan Li, Keyu Man, Partha Kanuparthy, Hanning Chen, Wei Sun, Sreen Tallam, Chenguang Zhu, Kevin Zhu, and Zhiyun Qian. TritonForge: Profiling-guided framework for automated Triton kernel optimization, 2025. arXiv preprint arXiv:2512.09196

    arXiv 2025

  12. [12]

    TritonBench: Benchmarking large language model capabilities for generating Triton operators

    Jianling Li, Shangzhan Li, Zhenye Gao, Qi Shi, Yuxuan Li, Zefan Wang, Jiacheng Huang, Haojie Wang, Jianrong Wang, Xu Han, Zhiyuan Liu, and Maosong Sun. TritonBench: Benchmarking large language model capabilities for generating Triton operators. InFindings of the Association for Computational Linguistics: ACL 2025, 2025

    2025

  13. [13]

    CUDA-L1: Improving CUDA optimization via contrastive reinforcement learning, 2025

    Xiaoya Li, Xiaofei Sun, Albert Wang, Jiwei Li, and Chris Shum. CUDA-L1: Improving CUDA optimization via contrastive reinforcement learning, 2025. arXiv preprint arXiv:2507.14111; accepted by ICLR 2026

    Pith/arXiv arXiv 2025

  14. [14]

    KernelEvolve: Scaling agentic kernel coding for heterogeneous AI accelerators at Meta, 2025

    Gang Liao, Hongsen Qin, Ying Wang, et al. KernelEvolve: Scaling agentic kernel coding for heterogeneous AI accelerators at Meta, 2025. arXiv preprint arXiv:2512.23236

    Pith/arXiv arXiv 2025

  15. [15]

    Harness engineering

    OpenAI. Harness engineering. OpenAI blog, 2025. https://openai.com/index/harness-engineering/

    2025

  16. [16]

    OpenAI. Codex. Official product page, 2026. https://openai.com/codex/

    2026

  17. [17]

    OpenCode: The open source AI coding agent

    OpenCode. OpenCode: The open source AI coding agent. GitHub repository, 2026. https://github.com/anomalyco/opencode

    2026

  18. [18]

    Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini

    Anne Ouyang, Simon Guo, Simran Arora, Alex L. Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini. KernelBench: Can LLMs write efficient GPU kernels?,

  19. [19]

    John, Burak Bartan, Natalie Serrino, Sachin Katti, and Zain Asgar

    Taras Sereda, Tom St. John, Burak Bartan, Natalie Serrino, Sachin Katti, and Zain Asgar. KForge: Program synthesis for diverse AI hardware accelerators, 2025. arXiv preprint arXiv:2511.13274

    arXiv 2025

  20. [20]

    Triton: An intermediate language and compiler for tiled neural network computations

    Philippe Tillet, Hsiang-Tsung Kung, and David Cox. Triton: An intermediate language and compiler for tiled neural network computations. InProceedings of the 3rd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages, pages 10–19, 2019

    2019

  21. [21]

    Matrix multiplication

    Triton contributors. Matrix multiplication. Triton documentation, 2026. https://triton-lang.org/main/getting-started/ tutorials/03-matrix-multiplication.html

    2026

  22. [22]

    triton.autotune

    Tritoncontributors. triton.autotune. Tritondocumentation, 2026.https://triton-lang.org/main/python-api/ generated/triton.autotune.html

    2026

  23. [23]

    triton.language

    Triton contributors. triton.language. Triton documentation, 2026.https://triton-lang.org/ main/python-api/triton.language.html

    2026

  24. [24]

    Triton-Ascend

    triton-lang contributors. Triton-Ascend. GitHub repository, 2026. https://github.com/triton-lang/triton-ascend

    2026

  25. [25]

    Mastering sparse CUDA generation through pretrained models and deep reinforcement learning

    Yaoyu Wang, Hankun Dai, Zhidong Yang, Junmin Xiao, and Guangming Tan. Mastering sparse CUDA generation through pretrained models and deep reinforcement learning. OpenReview, 2026. ICLR 2026 Oral

    2026

  26. [26]

    Astra: A multi-agent system for GPU kernel performance optimization, 2025

    Anjiang Wei, Tianran Sun, Yogesh Seenichamy, Hang Song, Anne Ouyang, Azalia Mirhoseini, Ke Wang, and Alex Aiken. Astra: A multi-agent system for GPU kernel performance optimization, 2025. arXiv preprint arXiv:2509.07506

    arXiv 2025

  27. [27]

    AscendCraft: Automatic Ascend NPU kernel generation via DSL-guided transcompilation, 2026

    Zhongzhen Wen, Shudi Shao, Zhong Li, Yu Ge, Tongtong Xu,YuanyiLin,andTianZhang. AscendCraft: Automatic Ascend NPU kernel generation via DSL-guided transcompilation, 2026. arXiv preprint arXiv:2601.22760. 10

    arXiv 2026

  28. [28]

    MultiKernelBench: A multi-platform benchmark for kernel generation, 2025

    Zhongzhen Wen, Yinghui Zhang, Zhong Li, Zhongxin Liu, Linna Xie, and Tian Zhang. MultiKernelBench: A multi-platform benchmark for kernel generation, 2025. arXiv preprint arXiv:2507.17773

    Pith/arXiv arXiv 2025

  29. [29]

    Towardsautomatedkernelgenerationin the era of LLMs, 2026

    Yang Yu, Peiyu Zang, Chi Hsu Tsai, Haiming Wu, Yixin Shen, Jialing Zhang, Haoyu Wang, Zhiyou Xiao, Jingze Shi, Yuyu Luo, Wentao Zhang, Chunlei Men, Guang Liu, andYonghuaLin. Towardsautomatedkernelgenerationin the era of LLMs, 2026. arXiv preprint arXiv:2601.15727. 11

    Pith/arXiv arXiv 2026

  30. [2025]

    arXiv preprint arXiv:2502.10517

    Pith/arXiv arXiv

  31. [2026]

    arXiv preprint arXiv:2603.24517. 9

    arXiv