<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:arxiv="http://arxiv.org/schemas/atom" xmlns="http://www.w3.org/2005/Atom">
  <id>https://arxiv.org/api/egf2BTg9+zrlGaK4iQhRDdY/qa8</id>
  <title>arXiv Query: search_query=cat:cs.PL AND (all:"memory safety" OR all:"compiler" OR all:"ownership")&amp;id_list=&amp;start=0&amp;max_results=30</title>
  <updated>2026-09-22T05:11:24Z</updated>
  <link href="https://arxiv.org/api/query?search_query=cat:cs.PL+AND+(all:%22memory+safety%22+OR+(all:%22compiler%22+OR+all:%22ownership%22))&amp;start=0&amp;max_results=30&amp;id_list=" type="application/atom+xml"/>
  <opensearch:itemsPerPage>30</opensearch:itemsPerPage>
  <opensearch:totalResults>2224</opensearch:totalResults>
  <opensearch:startIndex>0</opensearch:startIndex>
  <entry>
    <id>http://arxiv.org/abs/2609.24628v1</id>
    <title>Bridging the Vendor Gap: Enabling AMD GPU Support for Awkward Array via ROCm/HIP for the HL-LHC Era</title>
    <updated>2026-09-21T14:11:12Z</updated>
    <link href="https://arxiv.org/abs/2609.24628v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.24628v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>The High-Luminosity LHC (HL-LHC) will demand order-of-magnitude gains in analysis throughput, and increasingly those gains must come from GPUs that are not made by a single vendor. Leadership-class systems such as El Capitan, Frontier and LUMI are built on AMD accelerators, yet the Scikit-HEP analysis stack---and Awkward Array in particular---has grown up CUDA-first. We report on $rawkward$, a Rust-backed kernel engine that adds a ROCm/HIP backend for Awkward Array's nested, jagged, variable-length data structures. Our central finding is that a naive source-level port of CUDA kernels to HIP loses $5$--$10\times$ in performance on irregular kernels, because AMD's $64$-lane wavefronts, higher register pressure and more expensive divergence behave fundamentally differently from NVIDIA's $32$-thread warps. We show that a small, reusable set of optimization patterns---loop flattening, $128$-bit vectorized loads, splitting fused kernels, and profile-guided launch configuration---recovers CUDA-class performance without changing the public API. A Rust macro-and-match dispatch layer keeps a single, backend-agnostic call site while emitting vendor-specific kernel strategies, and the type system enforces buffer-size and lifetime correctness at compile time. On a two-socket AMD Instinct MI210 node we measure GPU speedups from $1.03\times$ (bandwidth-bound $sum$) up to $12.5\times$ ($count$) over $128$ EPYC~7763 CPU cores, and the Rust CPU kernels match or beat on aggregate the incumbent C++ kernels (geometric-mean runtime ratio $0.37\times$ across twelve kernels). We argue that these patterns constitute a practical recipe for performance-portable, vendor-agnostic HEP analysis kernels.</summary>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-21T14:11:12Z</published>
    <arxiv:comment>8 pages, 2 figures</arxiv:comment>
    <arxiv:primary_category term="cs.DC"/>
    <author>
      <name>Ianna Osborne</name>
    </author>
    <author>
      <name>Maxym Naumchyk</name>
    </author>
    <author>
      <name>Tai Sakuma</name>
    </author>
    <author>
      <name>Andres Rios-Tascon</name>
    </author>
    <author>
      <name>Peter Elmer</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.24436v1</id>
    <title>Categorical Message Passing Language (CaMPL): Syntax and Semantics</title>
    <updated>2026-09-21T11:30:33Z</updated>
    <link href="https://arxiv.org/abs/2609.24436v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.24436v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>We introduce a novel functional-style concurrent programming language called Categorical Message Passing Language (CaMPL) which is designed using the mathematics of linear actegories. This mathematical underpinning gives CaMPL programs useful properties such as deadlock freedom, and additionally, livelock freedom for programs without general recursive processes.
  We explore CaMPL's type system through a series of code examples. The current proto-alpha version of the compiler and the abstract machine is implemented in Haskell. A reader is encouraged to experiment with writing CaMPL programs either using the online compiler https://campl-app.vercel.app/ or by installing CaMPL from https://campl-ucalgary.github.io -- our website has detailed instructions on how to run CaMPL code.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LO" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-21T11:30:33Z</published>
    <arxiv:comment>54 pages</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Robin Cockett</name>
    </author>
    <author>
      <name>Daniel Kiyoshi Hashimoto</name>
    </author>
    <author>
      <name>Alexanna Little Berg</name>
    </author>
    <author>
      <name>Priyaa Varshinee Srinivasan</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.23954v1</id>
    <title>Djinnlang: Higher-Level Programming by Unambiguous Specification with an LLM in the Compiler</title>
    <updated>2026-09-21T00:00:09Z</updated>
    <link href="https://arxiv.org/abs/2609.23954v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.23954v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Programmers write formal specifications, and LLMs implement them, proving that each implementation matches its spec. Taken to its extreme, this makes specification languages the new programming languages. We argue that an unambiguity constraint is key: in addition to proving that its implementation satisfies the specification, the LLM must also prove that any other implementation satisfying it must produce the same outputs on the same inputs, i.e. that the relation formed by the constraints is deterministic. This leaves the LLM no leeway on program semantics: as with a conventional compiler, the generated code never needs to be read and can be regenerated from the spec at any time. Under this constraint and with a powerful LLM, the difference between a specification language and a programming language becomes essentially meaningless, and the LLM essentially becomes a part of the compiler toolchain. The arrangement doubles as a strong form of AI control: an untrusted model writes the code, yet its work is tightly checked by a verifier.
  To demonstrate that our LLM-in-the-compiler paradigm is feasible when supported by our unambiguity constraint, we present Djinnlang, a high-level specification language built for this future. A Djinnlang program consists only of specifications --- the programmer never writes executable code. In place of a traditional compiler, a symbolic translator lowers each spec to Dafny stubs and proof obligations, and a driver harness orchestrates an LLM that fills in implementations and proofs, all checked by the Dafny verifier. We evaluate our language and implementation on multiple examples and we show that it is self-hosting: an LLM can implement the Djinnlang translator from its specification and the reimplementation can verify itself.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-21T00:00:09Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Simon Henniger</name>
    </author>
    <author>
      <name>Stephen Chong</name>
    </author>
    <author>
      <name>Nada Amin</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.23759v1</id>
    <title>RPyForth: Exposing a Call-Shared Data Stack to a Meta-Tracing JIT Compiler</title>
    <updated>2026-09-20T17:17:01Z</updated>
    <link href="https://arxiv.org/abs/2609.23759v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.23759v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Forth is a concatenative language whose words share one data stack across calls, with a depth and call effects that need not be known before execution. That leaves a meta-tracing JIT compiler with no stack location it can name: a cell is reached through the stack pointer, so its accesses stay in the compiled code, and declaring every cell of the stack array instead ties what the compiler carries to the capacity the array reserves rather than to the depth a program uses.
  We answer with a fixed-width window over the top of the stack, a shared spill holding every deeper cell, and a decoding function that joins the two, on top of which call-entry normalization and adaptive entry are policies. Decoding shows that all of them preserve the logical stack and that a trace exit rebuilds data-stack state bounded by the window's width, not by the stack's depth. RPyForth realizes this in an RPython interpreter covering Forth's Core word set, with two scalar fields and eight frame positions and no static stack-effect analysis, and RPyFactor realizes the same window for a subset of Factor.
  Exposing the window to the compiler, rather than merely caching cells in it, is what pays. With the layout and the call policy held fixed, annotating the window's fields makes eighteen Shootout kernels 1.44-1.45x faster and six Appbench applications about 1.60x faster on two x86-64 machines, and 1.42-1.56x in RPyFactor. How the window is shaped and whether calls normalize it matter much less, varying by program with no setting winning everywhere. As a complete system, RPyForth is faster than gforth-fast and SwiftForth on both suites and reaches 1.90-2.36x the speed of VFX Forth on the kernels, while the applications, whose stacks are deeper and whose calls are far more frequent, remain its weak point at 0.68-0.76x. All timings measure repeated execution of an already-loaded program.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-20T17:17:01Z</published>
    <arxiv:comment>33 pages, 15 figures</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Yusuke Izawa</name>
    </author>
    <author>
      <name>Kota Hakamada</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.19583v1</id>
    <title>LLVM Translation Validation Automated with Large Language Models and Lean</title>
    <updated>2026-09-17T02:11:52Z</updated>
    <link href="https://arxiv.org/abs/2609.19583v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.19583v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>LLVM is the cornerstone of modern compilers, but its subtle intermediate representation (IR) semantics make transformations error-prone and necessitate formal verification. Alive2, a state-of-the-art translation validator based on satisfiability modulo theories, has achieved substantial success in automating the validation of LLVM transformations. However, it still faces scalability limitations, does not support symbolic bitwidths, and offers only bounded guarantees for loops. In contrast, interactive theorem provers such as Lean can address these cases but require substantial proof engineering. In this paper, we present Trivet, a framework combining large language models (LLMs) and Lean for automated translation validation of LLVM transformations. Trivet generates structured proof scaffolds based on source and target functions, automatically discharges obligations amenable to deterministic reasoning, and delegates transformationspecific obligations to LLMs. It produces refinement proofs or counterexample-based refutations, with every successful verdict checked by the Lean kernel. On 148 LLVM transformations, Trivet verifies or refutes 147, leaving one invalid case unresolved. Successful cases include 60 loop-free transformations with symbolic bitwidths, 27 cases from a restricted class of loop-containing transformations, and 10 complex valid fixed-bitwidth cases on which Alive2 times out. Compared with an unscaffolded baseline, scaffolding enables 26 additional proofs. On cases solved by both configurations, it reduces mean proof time by 75.9% and mean monetary cost by 88%.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-17T02:11:52Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Chunhao Liao</name>
    </author>
    <author>
      <name>Hongxu Xu</name>
    </author>
    <author>
      <name>Xintong Zhou</name>
    </author>
    <author>
      <name>Yizhou Zhang</name>
    </author>
    <author>
      <name>Chengnian Sun</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.19545v1</id>
    <title>Where the LLM Ends and Reliable Decisions Begin</title>
    <updated>2026-09-17T01:13:09Z</updated>
    <link href="https://arxiv.org/abs/2609.19545v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.19545v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Systems that turn natural-language descriptions of optimization problems into solver-ready code generally use a language model at every stage, including the final translation from a mathematical formulation into executable model-building code. We propose the ANVIL compiler architecture, where we separate these concerns. A language model is called only once, assisted by constraint guidance based on problem type, to produce a LaTeX formulation. A deterministic compiler then translates that LaTeX into code with no language model involvement. We describe the deterministic compiler (a normalizer, a recursive-descent parser producing a typed intermediate representation, analysis passes that bind symbols to a dataset schema, and a code emitter) and evaluate it on the 354 easy and hard problems of the NLP4LP benchmark. The compiler produced code for 329 of 354 formulations (92.9%), taking the deterministic path in every one of those cases and never falling back to model-generated code. Median compile time was below the 10ms resolution of our timer. Overall, our formulations achieved an accuracy of 98.9% over easy problems and 91.1% for hard problems. The gap between these compilation and accuracy figures is a key point of analysis, and we analyze it: formulations that failed to compile, problems that returned as infeasible, problems raising errors at runtime, and problems returning a wrong objective. Almost all of these errors trace back to the formulation rather than to the translation. ANVIL performs exceptionally well on leading benchmarks by using language models purely where they are effective, rather than as a catch-all tool.</summary>
    <category term="math.OC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-17T01:13:09Z</published>
    <arxiv:primary_category term="math.OC"/>
    <author>
      <name>Priyadarshan Patil</name>
    </author>
    <author>
      <name>Abhishek Basu</name>
    </author>
    <author>
      <name>Vikas Reddy</name>
    </author>
    <author>
      <name>Abhinav Gupta</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.19531v1</id>
    <title>Detecting Soft Errors in Parallel Software with LLM-tuned Instruction Duplication</title>
    <updated>2026-09-17T00:54:35Z</updated>
    <link href="https://arxiv.org/abs/2609.19531v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.19531v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>We propose PaRID (PaRallel Instruction Duplication), a software-directed soft error detection framework that requires only compile-time effort for multithreading parallel programs. PaRID addresses two key challenges: supporting parallel programs with mixed serial and parallel regions and minimizing performance overhead without relying on costly dynamic profiling. It combines parallel-aware code transformation with LLM-tuned performance modeling, guided by eight generalizable findings from an offline characterization study, to enable fast soft error detection in parallel applications. Evaluation on NPB benchmarks shows that PaRID reduces protection overhead from 162.79% to 59.84% on average and achieves up to 5x speedup while maintaining full error detection effectiveness.</summary>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-17T00:54:35Z</published>
    <arxiv:primary_category term="cs.DC"/>
    <author>
      <name>Yafan Huang</name>
    </author>
    <author>
      <name>Guanpeng Li</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.19410v1</id>
    <title>Splyce: SIMD Vectorization of Sparse Coiteration</title>
    <updated>2026-09-16T20:47:32Z</updated>
    <link href="https://arxiv.org/abs/2609.19410v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.19410v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Sparse tensor contractions are bottlenecked by sparse-sparse coiteration loops that resist standard loop vectorization. We present Splyce, an auto-vectorization framework in MLIR that overcomes this through a dual-path execution model. By decoupling coordinate intersection from pointer management via selective predication, Splyce inherently eliminates data-dependent branches as a side effect, allowing modern superscalar engines to maximize instruction-level parallelism and hide memory latency. Beyond simple branch elimination, our transformation exposes independent computation that can be executed concurrently, increasing functional-unit utilization that would otherwise be constrained by sequential dependencies. Evaluation across foundational sparse tensor kernels demonstrates performance ranging from 1.96X to 2.86X on synthetic inputs, with consistent speedups sustained across a vast majority of irregular real-world datasets from the SuiteSparse collection. Ultimately, Splyce demonstrates that by converting unpredictable control-flow into a predictable data stream, compiler-driven speculation can effectively reconcile the memory efficiency of compressed storage with the execution-unit throughput of modern superscalar architectures.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PF" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-16T20:47:32Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Kabilan Mahathevan</name>
    </author>
    <author>
      <name>Poorna Gunathilaka</name>
    </author>
    <author>
      <name>Kirshanthan Sundararajah</name>
    </author>
    <arxiv:doi>10.1145/3838684.3846860</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3838684.3846860" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.19206v2</id>
    <title>Programming In-Storage Computing with Located, Stateful Dataflow</title>
    <updated>2026-09-18T13:05:28Z</updated>
    <link href="https://arxiv.org/abs/2609.19206v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.19206v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>In-storage computing (ISC) reduces host--storage data movement by executing computation inside computational storage devices (CSDs). For multi-stage applications, realizing these benefits requires coordinating data placement, I/O--compute overlap, and device-resident state across the workflow, yet existing interfaces lack a unified abstraction for these decisions. We present Epic, an NVMe-based ISC stack that provides this abstraction by capturing data residency and lifetime in the program: location types declare logical residency, dataflow derives lifetimes for intermediate values and operation state within an invocation, and a keep primitive extends selected state across invocations. These semantics expose the complete offloaded workflow as a located, stateful dataflow. A storage-aware compiler transforms this workflow, performs movement-aware logical mapping and fusion, and exposes I/O--compute overlap; a runtime completes the plan using execution-time information, asynchronously binding work to physical resources and managing device-resident state. Across 12 file-scanning, database, and machine learning workloads, Epic is 1.6$\times$ faster on average than the strongest of five prior ISC systems, while achieving 4.2$\times$ speedup on average and up to 16.1$\times$ over the corresponding host baselines, and reducing application-side code by up to 14$\times$ in our implementations.</summary>
    <category term="cs.AR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-16T10:24:35Z</published>
    <arxiv:primary_category term="cs.AR"/>
    <author>
      <name>Yuyue Wang</name>
    </author>
    <author>
      <name>Zhenyu Zhang</name>
    </author>
    <author>
      <name>Glenn Reinman</name>
    </author>
    <author>
      <name>Huaicheng Li</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.16389v1</id>
    <title>Exo-GPU: Safe, Imperative, User-schedulable Programming for Tensor Cores</title>
    <updated>2026-09-14T21:55:23Z</updated>
    <link href="https://arxiv.org/abs/2609.16389v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.16389v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Modern GPUs require not only SIMT-style parallelism but also software-managed concurrency between compute and data movement to reach maximum performance. Performance engineers must reason about subdividing work into the hierarchy of computation resources (threads, warps, warpgroups, blocks, clusters), and, in many cases, also must use asynchronous tensor core and memcpy instructions on different levels of the memory hierarchy (registers, tensor core accumulators, shared memory, global memory). Unlike CPUs, where out-of-order execution is managed by hardware and hidden from programmers, GPUs expose explicit instruction reordering to software through these asynchronous instructions. Well-established GPU programming languages generally offer either direct low-level control without safety guarantees (e.g., CUDA C++ inline assembly or intrinsics) or easier-to-analyze, high-level abstractions (e.g., Triton's tile-based model) that hide asynchronous instructions in the compiler backend, which may prevent performance engineers from maximizing performance by tuning critical details. We propose Exo-GPU, an imperative, low-level language that creates minimal abstraction over CUDA. Our key idea is to treat parallelism and synchronization as mere annotations on sequential code rather than as fundamental control flow primitives, enabling verification that these constructs do not alter the program semantics. The benefit is twofold: programmers can reason about code without hidden control flow or mutation, while allowing the Exo-GPU compiler to verify sequential-parallel equivalence--guaranteeing that parallel execution is functionally equivalent to its sequential interpretation. We used Exo-GPU to author GEMM kernels for the H100 GPU, using wgmma, TMA, and split-k. Our kernels achieved over 80% of theoretical peak on large problem sizes, in some cases outperforming the vendor-provided CUBLAS library.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-14T21:55:23Z</published>
    <arxiv:comment>29 pages, 22 figures, no conference publication. NOTE: red/blue arcs on page 5 are part of the exposition, NOT editing marks</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>David Zhao Akeley</name>
    </author>
    <author>
      <name>Yuka Ikarashi</name>
    </author>
    <author>
      <name>Jonathan Ragan-Kelley</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.16079v1</id>
    <title>QuickerChick</title>
    <updated>2026-09-13T19:23:05Z</updated>
    <link href="https://arxiv.org/abs/2609.16079v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.16079v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Property-based testing (PBT) with QuickChick relies on extracting Rocq programs to OCaml. However, this extraction mechanism, while crucial for QuickChick to function, has significant performance implications. In this work, we describe how we optimized QuickChick, exploiting various opportunities offered by program extraction to significantly improve each test's extraction, compilation, and running time. We also evaluate these improvements using the ETNA benchmarking platform for PBT to assess how individual improvements impacted the overall test run time.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-13T19:23:05Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Ivan Mladenov</name>
    </author>
    <author>
      <name>Alperen Keles</name>
    </author>
    <author>
      <name>Leonidas Lampropoulos</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.14527v2</id>
    <title>Equality saturation theory exploration à la carte</title>
    <updated>2026-09-18T14:36:26Z</updated>
    <link href="https://arxiv.org/abs/2609.14527v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.14527v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>Rewrite rules are critical in equality saturation, an increasingly popular technique in optimizing compilers, synthesizers, and verifiers. Unfortunately, developing high-quality rulesets is difficult and error-prone. Recent work to automatically infer rewrite rules does not scale to large terms or grammars. Users struggle to guide inference and incrementally construct rulesets because existing rule inference tools are monolithic and opaque. As a result, most equality saturation users still manually develop and maintain rulesets.
  This paper proposes Enumo, a new domain-specific language for programmable theory exploration. Enumo provides a small set of core operators that enable users to strategically guide rule inference and incrementally build rulesets. Short Enumo programs easily replicate results from state-of-the-art tools like Ruler, but Enumo programs can also scale to infer deeper rules from larger grammars than prior approaches. Enumo's composable operators even facilitate developing new strategies for ruleset inference. We introduce a new fast-forwarding strategy which does not require evaluating terms in the target language, and thus supports domains that were out of scope for prior work. Enumo is also easy to extend: two new operators suffice to incorporate large language models into rule inference, where they complement guided search.
  We evaluate Enumo and fast-forwarding across a variety of domains. Compared to state-of-the-art techniques, Enumo can synthesize better rulesets over a diverse set of domains, in some cases matching the effects of manually developed rulesets in systems driven by equality saturation.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-13T14:06:39Z</published>
    <arxiv:comment>43 pages, 9 figures, Extended version of the OOPSLA 2023 paper, submitted to the Journal of Functional Programming. v2: corrected the accent in the title metadata; paper unchanged</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Anjali Pal</name>
    </author>
    <author>
      <name>Brett Saiki</name>
    </author>
    <author>
      <name>Ryan Tjoa</name>
    </author>
    <author>
      <name>Cynthia Richey</name>
    </author>
    <author>
      <name>Amy Zhu</name>
    </author>
    <author>
      <name>Oliver Flatt</name>
    </author>
    <author>
      <name>Max Willsey</name>
    </author>
    <author>
      <name>Zachary Tatlock</name>
    </author>
    <author>
      <name>Chandrakana Nandi</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.13930v1</id>
    <title>Enforcement of In-Kernel Stateful Security Policies via eBPF</title>
    <updated>2026-09-12T13:24:44Z</updated>
    <link href="https://arxiv.org/abs/2609.13930v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.13930v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Many attacks against workloads running on multi-tenant systems are multi-step and history-dependent: sequences of innocuous operations whose malicious nature emerges only over an execution trace. Defending against them requires security policies that are stateful, are enforced within the kernel, and have a precise semantics. Currently deployed proposals fail on at least one count: kernel's built-in syscall filtering and classical MAC frameworks are stateless, while current eBPF-based tools express their policies through ad hoc YAML rules that cannot capture temporal relations among events, and whose semantics is defined only by the implementation.
  We present BPFence, an in-kernel runtime-verification framework that satisfies the properties above. BPFence provides a policy language with a formal semantics that can express temporal relations among events. It also provides a type system that statically distinguishes events the kernel can control from those it can only observe. Every well-typed policy is compiled into a finite-state monitor proved correct with respect to its semantics, and then into eBPF programs that run inside the kernel. We evaluate BPFence on seven case studies drawn from real-world attack patterns, and on a set of micro- and macro-benchmarks to show that the enforcement overhead remains compatible with production deployment.</summary>
    <category term="cs.CR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-12T13:24:44Z</published>
    <arxiv:comment>This is the extended version of the paper appearing in Proc. ACM SIGSAC Conference on Computer and Communications Security (CCS '26). It includes the appendices with the full formal development and the additional language constructs omitted from the proceedings version</arxiv:comment>
    <arxiv:primary_category term="cs.CR"/>
    <author>
      <name>Letterio Galletta</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.11923v1</id>
    <title>GPU-CFR: 80x Faster Counterfactual Regret Minimization by Compiling the Game to Static Dataflow and CUDA Graph Replay</title>
    <updated>2026-09-10T17:58:14Z</updated>
    <link href="https://arxiv.org/abs/2609.11923v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.11923v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Counterfactual regret minimization (CFR) is one of the few large numerical workloads that still runs faster on CPUs than on GPUs. Each iteration sweeps a game tree with up to billions of states in millions of small, interdependent gather and scatter steps issued through a generic tree interface. On a GPU every kernel finishes in microseconds, so kernel launches and framework dispatch dominate the run time, and prior GPU implementations have lost to optimized CPU code. We observe that for a fixed game, everything about a CFR iteration except the numerical values is known before the first iteration runs. We propose GPU-CFR, a compiler and runtime built on this observation. It compiles any game once into static dataflow: flat edge and information-set arrays, precomputed indices, and depth-level batched passes fix the entire operation sequence, and only solver state changes between iterations. Static chance folding, depth-level execution blocks, and a dual-lane reach buffer cut the number of framework operations by up to 18.1x. Because shapes, indices, and buffer addresses never change, CUDA Graph Replay records the iteration once and replays it with a single graph launch. On one A100, across an eight-game suite that spans card games, dice games, and board games, GPU-CFR runs 29.8--80.4x faster than the fastest prior GPU CFR on the same accelerator, and 14--258x faster than LiteEFG, one of the fastest open-source CPU implementations, on the four largest games. The compiled representation carries most of that margin: on eight CPU threads with no accelerator it is already 2.2--51.1x faster than the GPU baseline. On the CPU the optimized path reproduces the reference iterates bitwise, and tree construction and graph capture pay for themselves within the first solve. GPU-CFR beats every CPU and GPU baseline on the mid-to-large games of the suite without changing the update rule.</summary>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.GT" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.MS" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-10T17:58:14Z</published>
    <arxiv:primary_category term="cs.DC"/>
    <author>
      <name>Boning Li</name>
    </author>
    <author>
      <name>Longbo Huang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.11356v1</id>
    <title>Taming Bitwise Behavior in GPU Kernels with Tensor Core: Black-Box Reconstruction, Compiler Enforcement, and Static Verification</title>
    <updated>2026-09-10T10:39:21Z</updated>
    <link href="https://arxiv.org/abs/2609.11356v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.11356v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Determinism and numerical reproducibility are increasingly required of GPU kernels in machine learning systems, yet deterministic implementations of the same kernel can still differ bit for bit. Floating-point reduction order is the primary cause, alongside partial-sum precision, fused multiply-add operations, and rounding placement. These choices may be hand-coded, selected by a block-level language such as Triton, or hidden inside a closed-source library such as cuBLAS or rocBLAS. A tile shape chosen for performance therefore also determines the arithmetic, potentially breaking batch invariance. Preserving a fixed order can cost up to 20 percent, while an autotuner cannot identify which configurations are bitwise equivalent.
  We characterize the factors determining the bitwise behavior of reductions and general matrix multiplication (GEMM). First, we introduce a descriptor of GEMM reduction order, including the partitioning of K in split-K GEMM. Using it, we perform the first black-box reconstruction of a closed-source library's arithmetic for bit-level correctness. Our family of Triton GEMMs matches NVIDIA cuBLAS in all tested cases on Blackwell and Hopper. For realistic LLM shapes with fused epilogues, it matches or exceeds torch.compile performance. Second, we enforce balanced-tree reduction during Triton lowering and introduce a data-layout optimization that brings 19 of 27 kernels on GB300 and H100 within 10 percent of free-order performance. Third, we develop sound static checkers for bitwise equivalence between compiled GPU kernels, including the first checker spanning NVIDIA PTX and AMD GCN. Integrated into Triton's autotuner, the checker restricts search to a single bit-equivalence class.</summary>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PF" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-10T10:39:21Z</published>
    <arxiv:primary_category term="cs.DC"/>
    <author>
      <name>Ziteng Yang</name>
    </author>
    <author>
      <name>Nicholas J. Riasanovsky</name>
    </author>
    <author>
      <name>Warren Deng</name>
    </author>
    <author>
      <name>Vivek Sarkar</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.09641v1</id>
    <title>UnsafeChecker: Finding Soundness Bugs in Rust Safe Abstractions</title>
    <updated>2026-09-09T02:57:26Z</updated>
    <link href="https://arxiv.org/abs/2609.09641v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.09641v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Rust guarantees memory safety without garbage collection through a strict ownership and borrowing system. However, for low-level systems programming, many widely used libraries rely on the unsafe keyword. These libraries encapsulate raw-pointer operations behind safe APIs to form safe abstractions. A single mistake in this internal unsafe code can break its safety contract, rendering the abstraction unsound and allowing safe clients to trigger undefined behavior. Detecting these potential soundness violations is challenging. Existing static analysis tools for C/C++ ignore Rust-specific safety contracts, while current Rust tools lack the deep semantic modeling required to track the contexts that raw pointers erase.
  To address this gap, we present UnsafeChecker, a compiler-integrated static analysis framework for detecting potential soundness violations in Rust safe abstractions. UnsafeChecker analyzes Rust MIR using a flow-sensitive abstract interpretation that maintains a shared state with three components: ownership, object validity, and layout. Each warning rule consumes the subset of facts needed for the corresponding Rust safety obligation. UnsafeChecker reports both instruction-level undefined behavior and boundary-level contract violations that may escape through safe APIs. We evaluate UnsafeChecker on a benchmark of 46 RustSec vulnerabilities, which contain 53 ground-truth bugs. UnsafeChecker outperforms several state-of-the-art tools, detecting 32 CVEs and covering 36 bugs (67.9% recall) with 51.6% alert-level precision. Furthermore, in a large-scale scan of real-world crates on crates.io, UnsafeChecker uncovered 114 previously unknown bugs across 83 crates, with 45 confirmed and 27 already fixed by maintainers.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-09T02:57:26Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Xizhe Yin</name>
    </author>
    <author>
      <name>Yaokun Zhang</name>
    </author>
    <author>
      <name>Yang Feng</name>
    </author>
    <author>
      <name>Baowen Xu</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.09270v1</id>
    <title>Python in the front, party in the Backline: compiling quantum workloads across CPUs, GPUs, and FPGAs</title>
    <updated>2026-09-08T18:00:00Z</updated>
    <link href="https://arxiv.org/abs/2609.09270v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.09270v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Moving from quantum research and development to production-grade, fault-tolerant quantum workload execution remains one of the most significant challenges facing quantum platform builders. While Python frameworks have enabled an easy entry point for quantum algorithm design, the low-latency requirements for real-time quantum error correction (QEC) demand performance that traditional interpreted environments cannot provide. FPGAs and ASICs play a central role at these layers, but their specialized programming models make development rigid and time-consuming. CPUs, GPUs, and other accelerators introduce a different challenge: as infrastructure becomes increasingly heterogeneous, programming across different devices and their associated abstractions becomes more complex. Allowing researchers to write workloads in high-level languages that map to low-latency execution across diverse distributed target platforms will enable the development of key infrastructure for utility-scale quantum systems. For this, we introduce $\textit{Backline}$, a heterogeneous compilation and runtime framework built within PennyLane and Catalyst. Backline allows us to design and build quantum-classical workloads for high-performance and low-latency devices, with compilation directly from a Python interface through MLIR. We demonstrate the compilation and execution of several quantum workloads with low-latency data movement across a mix of CPUs, GPUs, and FPGAs, for both local and distributed remote hardware targets, all from a vendor-agnostic Python frontend. With an AMD VPK120 FPGA board as the controller, issuing each round from its hardware-handshake engine, we measured median steady-state round-trip latencies over RoCE v2 of $2.305~μ$s to an AMD Ryzen Threadripper PRO CPU and $4.5~μ$s to an AMD Instinct MI210 GPU across $10^6-1$ rounds per path, demonstrating microsecond-scale synchronous co-processing.</summary>
    <category term="quant-ph" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-08T18:00:00Z</published>
    <arxiv:primary_category term="quant-ph"/>
    <author>
      <name>Joseph K. L. Lee</name>
    </author>
    <author>
      <name>Mehrdad Malekmohammadi</name>
    </author>
    <author>
      <name>Hong-Sheng Zheng</name>
    </author>
    <author>
      <name>Shuli Shu</name>
    </author>
    <author>
      <name>Cheick Doumbia</name>
    </author>
    <author>
      <name>Kalman Szenes</name>
    </author>
    <author>
      <name>Mehran Zamani Abnili</name>
    </author>
    <author>
      <name>Thomas Ainsworth</name>
    </author>
    <author>
      <name>Matthew Seymour</name>
    </author>
    <author>
      <name>Thomas Germain</name>
    </author>
    <author>
      <name>Leonhard Neuhaus</name>
    </author>
    <author>
      <name>Josh Izaac</name>
    </author>
    <author>
      <name>Lee J. O'Riordan</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.08075v1</id>
    <title>Mapping Dynamic, Hierarchical Quantum Circuits</title>
    <updated>2026-09-08T00:37:42Z</updated>
    <link href="https://arxiv.org/abs/2609.08075v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.08075v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Qubit mapping is a critical pass in quantum compilation. Despite various advances, dynamic circuits, those exhibiting data dependent control-flow, often resulting from qubit measurements, are not yet supported by the vast majority of available qubit mappers. The crucial limitation to overcome is the dependence on flat, one-dimensional representations of circuits. Further, qubit mappers currently lack compiler abstractions that capture the hierarchical nature of circuits, hindering the qubit mapping process. In this paper, 1 we introduce a new qubit mapping method and analyses to tackle hierarchical dynamic circuits. Our novelty resides in four key aspects: modeling (statically) sub-circuits in disjoint control-flow paths, introducing a novel Qubit Reconciliation pass to maintain consistency between sub-circuit and control-flow boundaries, a loop-entry remapping pass, and a refined cost function enhanced for SWAP count, circuit depth, circuit latency and error. We demonstrate the efficiency of our approach on a wide range of dynamic circuits on two monolithic Quantum Processing Units of 127 and 156 qubits, and on chiplet hexagon-based QPUs. On monolithic QPUs, our qubit mapper improves the SWAP count by up to 52%, depth by up to 18%, latency by up to 18.6%, and error by up to 40%. On chiplet architectures, we achieve improvements of up to 36% on SWAP count, 8.7% on depth, 15% on latency, and 15% of error.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-08T00:37:42Z</published>
    <arxiv:comment>To appear in the Proceedings of the 2027 International Symposium on Code Generation and Optimization (CGO 2027)</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Marouane Benbetka</name>
    </author>
    <author>
      <name>Merwan Bekkar</name>
    </author>
    <author>
      <name>Bokyeong Yoon</name>
    </author>
    <author>
      <name>Riyadh Baghdadi</name>
    </author>
    <author>
      <name>Martin Kong</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.06743v1</id>
    <title>Staged Hybrid Quantum-Classical Programming</title>
    <updated>2026-09-06T17:35:18Z</updated>
    <link href="https://arxiv.org/abs/2609.06743v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.06743v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Hybrid quantum-classical computing systems consist of a classical control system that sends quantum circuits and receives measurement results from a quantum co-processor. Such systems allow us to model algorithms that require the classical control system to generate quantum circuits on the fly, potentially based on prior measurement results. This is challenging, as the classical control system must generate quantum circuits that manipulate live quantum states. In this setting, the classical control system is generating further quantum circuits while the quantum co-processor is internally maintaining the state of the live qubits; this is not ideal, since this not only is costly but also introduces additional sources of noise to the live qubits. Thus, we want to minimize the latency between receiving measurement results and sending the next quantum circuit to be executed by pre-computing quantum circuits.
  We introduce HyQ (pronounced haiku), a multi-modal language based on adjoint logic that pre-generates quantum circuits before executing a hybrid quantum-classical program. We achieve this by separating our semantics into two distinct stages: 1) compile-time generation of quantum circuits and classical runtime code and 2) execution of the classical runtime code that instruments the quantum co-processor. This separation between stages allows us to formally guarantee that all circuit-generation logic occurs before the instrumentation logic, i.e., the actual runtime, and minimizes the idling of the quantum co-processor at runtime. We give a type system, a circuit-normalization semantics for the compile-time stage, which eagerly performs all circuit-generation logic, and a runtime semantics for HyQ that corresponds to the second stage. We prove type preservation and progress for both semantics.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LO" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-06T17:35:18Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Chuta Sano</name>
    </author>
    <author>
      <name>Peng Fu</name>
    </author>
    <author>
      <name>Ryan Kavanagh</name>
    </author>
    <author>
      <name>Jennifer Paykin</name>
    </author>
    <author>
      <name>Brigitte Pientka</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.06328v1</id>
    <title>SparseConflicts: Handling Conflicting Data Layouts in Sparse Tensor Contractions</title>
    <updated>2026-09-06T01:25:41Z</updated>
    <link href="https://arxiv.org/abs/2609.06328v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.06328v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Optimizing sparse tensor computations is challenging due to the use of compressed storage formats, which leads to non-affine loop nests and a vast, complex schedule space. The performance of a given schedule is sensitive to the sparsity pattern of the input tensors, making it difficult to find a single optimal solution. When input tensors in the same tensor contraction have conflicting data layouts in relation to the iteration order, it requires costly-both in time and memory-layout transformation, such as transposition. A promising but under-explored alternative is to generate a schedule that avoids explicit transposition, but this has not been systematically supported in existing compilers.
  This paper presents a new code generation strategy that generalizes the intermediate representation of the TACO sparse tensor compiler to generate a single loop nest, circumventing explicit transposition of tensors when the tensors have conflicting data layout iteration orders. We extend TACOś iteration graph to express a search-based strategy for locating elements in tensors with conflicting layouts, and we introduce new intermediate representation nodes to lower these schedules to efficient code. This enables the systematic generation of loops that do not require explicit transposition, thus avoiding the overhead of materializing temporary tensors.
  We evaluate our approach on a set of sparse tensor contractions using both real-world and synthetic datasets. Our results demonstrate that for computations with misaligned data layouts, our fused approach achieves up to 2x speedup for some sparsity patterns over the traditional approach of explicitly creating a transposed temporary. We also provide guidelines for when this new scheduling strategy is likely to be beneficial.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-06T01:25:41Z</published>
    <arxiv:comment>25 pages, 18 figures, 2 tables</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Adhitha Dias</name>
    </author>
    <author>
      <name>Kirshanthan Sundararajah</name>
    </author>
    <author>
      <name>Artem Pelenitsyn</name>
    </author>
    <author>
      <name>Milind Kulkarni</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.06301v1</id>
    <title>Compiling Linear Datalog to SQL for Program Analysis</title>
    <updated>2026-09-05T23:22:25Z</updated>
    <link href="https://arxiv.org/abs/2609.06301v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.06301v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Datalog is a declarative query language that has proven highly effective for expressing static program analyses. Although Datalog has deep roots in database theory, most recent advances have largely emerged from the programming languages and compiler communities, with systems such as Soufflé. In contrast, modern relational engines have made significant progress in optimizing recursive SQL.
  This paper revisits the connection between Datalog and relational databases, advocating recursive SQL as a backend for Datalog evaluation. We present a compilation framework that translates Datalog programs, particularly those in the Linear Datalog fragment, into equivalent recursive SQL queries. To bridge the gap between Datalog and SQL, the compiler routes every program through an intermediate language called Midlog. The compiler additionally recovers functional dependencies from the program and exposes them as schema keys, unlocking the engine's standard query optimizations. This approach enables existing database engines to execute a broad class of program analyses, outperforming the Soufflé engine by up to an order of magnitude on the Umbra backend. Umbra achieves a geometric-mean speedup of 5.46$\times$ at 8 threads, whereas DuckDB is competitive with Soufflé single-threaded and is slower at 8 threads (geometric-mean speedup of 0.68$\times$). Furthermore, the generated SQL is portable; it runs on seven database systems without any engine modification. Our results highlight what the relational engines require to fully support Datalog for large-scale program analysis.</summary>
    <category term="cs.DB" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-05T23:22:25Z</published>
    <arxiv:primary_category term="cs.DB"/>
    <author>
      <name>Amir Shaikhha</name>
    </author>
    <author>
      <name>Anna Herlihy</name>
    </author>
    <author>
      <name>Hung Ngo</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.04904v1</id>
    <title>CPL: A Compact C-like Systems Language with Explicit Low-Level Control</title>
    <updated>2026-09-04T09:07:15Z</updated>
    <link href="https://arxiv.org/abs/2609.04904v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04904v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>This paper presents Cordell Programming Language (CPL), a compact C-like systems language that retains C's direct access to memory, layout, and machine interfaces while experimenting with a smaller grammar and selected conveniences from newer languages. Also this paper studies whether C-like are more convenient to use for compiler experiments than modern approaches and paradigms. While the language and compiler provide primitive values, pointers, arrays, containers with methods, unions, generic functions, overloads, entry-point and section control, system calls, and inline assembly, they do not provide high-level constructs such as classes, built-in methods, a standard library, or memory protection. The article describes the language design, compiler pipeline, target backends, static-analysis architecture, and OS-facing use cases, then evaluates the prototype backend with reproducible x86_64 and i386 microbenchmarks against C compiler baselines. The obtained results suggest that the compiler can produce code comparable to that produced by production compilers such as GCC and Clang, as well as by small compilers such as TinyC and SmallerC.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-04T09:07:15Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Nikolay Fot</name>
    </author>
    <author>
      <name>Alexander Vinarsky</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.04585v1</id>
    <title>JLIR: A Julia-Native MLIR-Inspired Intermediate Representation with Automatic JACC Kernel Extraction</title>
    <updated>2026-09-04T00:35:54Z</updated>
    <link href="https://arxiv.org/abs/2609.04585v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04585v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>The Multi-Level Intermediate Representation (MLIR) has made reusable compiler infrastructure practical for domain-specific computation. However, MLIR's strong compile-time type requirements and low-level (C++) extension model can be a poor match for high-level, dynamically specialized languages such as Julia. MLIR has several drawbacks for dynamic programming languages in terms of the type system and level of abstraction. It is thus extremely challenging for non-compiler or scientific computing users to introduce new programming abstractions and express algorithm implementations in a form that remains both natural and optimizable. As a result, library interfaces for linear algebra, mesh processing, partial differential equations, and related domains often sit outside the compiler optimization path. We present JLIR (Julia-native Level Intermediate Representation), a Julia-native intermediate representation framework that brings the main benefits of MLIR-style multi-level, dialect-oriented compilation into the Julia ecosystem while remaining usable as ordinary Julia code. JLIR represents Julia programs before low-level lowering, supports extensible operations and transformation passes through Julia's language mechanisms, and allows partially typed programs to remain transformable until concrete types are known. The framework includes built-in dialects for arithmetic, control flow, functions, structured loops, and memory operations, and it also includes a lightweight mechanism for adding new domain operations without modifying the core system. To demonstrate JLIR's capabilities, we applied it to automatic Julia for Accelerators (JACC) kernel generation.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-04T00:35:54Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Narasinga Rao Miniskar</name>
    </author>
    <author>
      <name>Seyong Lee</name>
    </author>
    <author>
      <name>Keita Teranishi</name>
    </author>
    <author>
      <name>Jeffrey S Vetter</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.04535v2</id>
    <title>An Empirical Analysis of CodeQL False Positives and Query Refinements for Java Vulnerabilities</title>
    <updated>2026-09-15T01:48:54Z</updated>
    <link href="https://arxiv.org/abs/2609.04535v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04535v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>Static application security testing (SAST) tools help developers find vulnerabilities before deployment, but false positives create substantial triage effort. We study whether CodeQL false positives in Java security analysis form recurring, explainable patterns that can be reduced by refining the analysis. We run CodeQL's Java security query suite on 167 CVE instances from 110 projects, focusing on the ten queries with the highest false positive rates. We manually review 500 sampled false positive paths and locations and construct a source-level taxonomy. The five categories are Missed Path Constraint or Sanitization (36.6%), Benign Execution Context (29.4%), Missing Trust Boundary Modeling (27.6%), Imprecise Concurrency Modeling (5%), and Imprecise Sink Modeling (1.4%).
  Guided by these findings, we implement CodeQL refinements that detect and filter recurring false positive patterns at the query level. The refinements remove 81.8% of reviewed false positives. Across the full selected-query dataset, they remove 15.8% of reported paths and locations while retaining 7 of 8 true positives. This shows that many false positives can be reduced in the analysis, although fixed refinements often depend on project-specific context. To address this generalization gap, we evaluate whether agentic coding tools can adapt refinement patterns to new projects. Given our patterns as templates, the two tools succeed on 56% and 62% of tasks, with query compile-pass rates above 90%. Without this guidance, both succeed on only 28%, while compile rates fall to 30-36%. These results support a refinement-oriented SAST workflow in which recurring false positives are modeled in CodeQL queries and automatically adapted to different project contexts, reducing repeated triage.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-03T22:48:21Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Amirali Sajadi</name>
    </author>
    <author>
      <name>Saikat Dutta</name>
    </author>
    <author>
      <name>Preetha Chatterjee</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.04523v1</id>
    <title>MaxKernel: Agentic Kernel Generation for TPUs</title>
    <updated>2026-09-03T22:22:37Z</updated>
    <link href="https://arxiv.org/abs/2609.04523v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04523v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Designing and authoring high-performance custom kernels for accelerators is a complex task that requires deep hardware-level expertise. Large Language Models (LLM) can be leveraged together with real-time compiler feedback to build agentic systems for kernel generation. In this work, we present MaxKernel, a multi-agent system that implements three distinct paradigms for TPU kernel development: (1) a Human-in-the-Loop (HITL) agent for collaborative, step-by-step design; (2) an Autonomous (Auto) agent that executes a fully automated, metric/trace-driven optimization loop; and (3) a Graph-Based Autonomous Search that scales the Auto agent for global exploration of the design space. All three paradigms leverage a shared pool of specialized sub-agents to handle planning, implementation, self-debugging, testing, and hardware profiling. We evaluate MaxKernel on JaxBench, a comprehensive suite of 50 diverse kernel tasks for TPUs, alongside complex, real-world workloads from state-of-the-art open-source models. We demonstrate that MaxKernel consistently generates highly optimized implementations, matching expert hand-tuned baselines and delivering significant performance across the benchmark. Our agent is open-sourced and available https://github.com/AI-Hypercomputer/accelerator-agents/tree/main/MaxKernel.</summary>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PF" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-03T22:22:37Z</published>
    <arxiv:comment>14 pages, 6 figures, 4 tables</arxiv:comment>
    <arxiv:primary_category term="cs.AI"/>
    <author>
      <name>Shangkun Wang</name>
    </author>
    <author>
      <name>Nina Cai</name>
    </author>
    <author>
      <name>Charles Hoong</name>
    </author>
    <author>
      <name>Julian Walker</name>
    </author>
    <author>
      <name>Gerson Kroiz</name>
    </author>
    <author>
      <name>George Vanica</name>
    </author>
    <author>
      <name>Deepak Patil</name>
    </author>
    <author>
      <name>Andi Gavrilescu</name>
    </author>
    <author>
      <name>Hassan Sipra</name>
    </author>
    <author>
      <name>Sethu Sankaran</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.04372v1</id>
    <title>Corten - Foundational Verification of Rust Programs</title>
    <updated>2026-09-03T18:37:50Z</updated>
    <link href="https://arxiv.org/abs/2609.04372v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04372v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>We present Corten, a foundational verification framework for Rust programs in the Rocq theorem prover, built on the Iris separation logic framework. Corten provides the first semantics of surface-level Rust mechanized in a proof assistant with an attached program logic, directly grounded in the Rust Reference: it deeply embeds the Typed High-level Intermediate Representation (THIR) into Rocq and formalises Rust's dynamic semantics as a weakest-precondition predicate transformer calculus. By operating at THIR rather than on internal compiler representations, Corten proof goals display the THIR AST, which pretty-prints to surface Rust, keeping verification close to the source code and facilitating maintainability as code evolves. Atop this semantics, Corten develops a program logic and a syntax-directed proof automation layer; the program logic includes defunctionalized continuation stacks that keep proof goals first-order and compact. Soundness is established incrementally, construct by construct, against an interaction-trees denotation. A synthetic test suite demonstrates a two-to-four times reduction in proof size compared to raw semantic proofs. We further showcase Corten on a buddy allocator case study, verifying memory safety of the allocation and deallocation functions, laying the groundwork for end-to-end verification in a shared Rocq semantic foundation spanning hardware-software boundaries.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-03T18:37:50Z</published>
    <arxiv:comment>41 pages, 13 figures</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>František Farka</name>
    </author>
    <author>
      <name>Carmine Abate</name>
    </author>
    <author>
      <name>Sven Linker</name>
    </author>
    <author>
      <name>Sebastian Ertel</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.03114v1</id>
    <title>Enhancing the Power of Polyhedral-Based Optimizations with Coordinate-Based Hill Climbing</title>
    <updated>2026-09-02T19:50:00Z</updated>
    <link href="https://arxiv.org/abs/2609.03114v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.03114v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>This paper describes our experience extending the polyhedral compiler Pluto with a lightweight, coordinate-wise hill-climbing tuner that adjusts numeric transformation parameters, such as tile sizes and thread-block dimensions, after Pluto selects the kernel's loop structure. To ensure fast convergence and escape local minima, hill climbing is augmented with two techniques: expanded neighborhood exploration and a shortest-hop refinement phase. On x86 and ARM CPUs, tuned kernels outperform Pluto's default configuration (1.06-1.28x geometric mean speedup across 11 benchmarks) and static optimizers (Clang -O3, Polly, IOOpt), reaching performance competitive with the AutoTVM autotuner at substantially lower search cost. Applying the same technique to GPU thread-block allocation on an NVIDIA A100 yields 5.5-8.5% improvement over default configurations. These results position post-optimization parameter tuning as a practical middle ground between fixed-cost-model polyhedral compilation and full autotuning.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-02T19:50:00Z</published>
    <arxiv:comment>26 pages, 75 references, 15 figures and 3 tables</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Gaurav Verma</name>
    </author>
    <author>
      <name>Michael Canesche</name>
    </author>
    <author>
      <name>Fernando Magno Quintão Pereira</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.22220v1</id>
    <title>Measuring the Checker: Mutation Analysis for GPU-Kernel Benchmark Oracles</title>
    <updated>2026-09-02T10:30:05Z</updated>
    <link href="https://arxiv.org/abs/2609.22220v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.22220v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Benchmarks for LLM-generated GPU kernels decide correctness with a few random inputs and a loose floating-point tolerance, and their verdicts now feed leaderboards and reinforcement-learning rewards. Recent work agrees these checkers are weak and patches them by hand---extra input distributions, fuzzing recipes, tighter tolerances---with no way to \emph{measure} whether any patch suffices. We introduce mutation analysis as an adequacy metric for kernel-benchmark oracles: deterministic rules inject 10{,}303 compilable faults into verified CUDA implementations of 188 KernelBench problems, 7{,}384 of them with an independent kill witness; any test protocol is scored by the fraction it detects. The official check misses \textbf{one in six} witnessed faults (16.9%), deterministically, and the misses are skewed by family: 8.7% of arithmetic faults escape, but 78.6% of precision faults do. The metric explains why (a tolerance blind band growing with reduction size; a measured ceiling on input aggressiveness set by legitimate floating-point variance), audits the strongest existing patch (KernelBench-Verified's gain splits into $+4.0$ points from hidden inputs and $+4.5$ from tighter tolerance, a split its authors could not compute), and exposes a published fuzzing recipe that rejects \emph{correct} kernels 107 times. Optimizing suites over the kill matrix reaches 98.0% detection with two inputs per problem (94.8% held-out), and the measurement's fault taxonomy teaches a test generator more than the raw faults themselves. Across 48 whole architectures, the blindness grows with scale, concentrating in deep homogeneous pipelines, and two problems prove unrefereeable: their official references violate the benchmark's own tolerance against fp64. We release everything as \href{https://huggingface.co/datasets/Elfsong/KernelBench-M}{KernelBench-M}.</summary>
    <category term="cs.LG" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-02T10:30:05Z</published>
    <arxiv:primary_category term="cs.LG"/>
    <author>
      <name>Mingzhe Du</name>
    </author>
    <author>
      <name>Anh Tuan Luu</name>
    </author>
    <author>
      <name>Dong Huang</name>
    </author>
    <author>
      <name>See-Kiong Ng</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.02048v1</id>
    <title>Type-Directed, Secure-by-Construction Enclave Partitioning for LLVM</title>
    <updated>2026-09-02T03:25:29Z</updated>
    <link href="https://arxiv.org/abs/2609.02048v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.02048v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Trusted Execution Environments (TEEs) provide hardware-supported isolation through enclaves that protect code and data independently of software abstractions. However, TEEs alone cannot enforce information-flow security. This problem is further aggravated in LLVM-like low-level languages that allow unrestricted pointer manipulation and unstructured control flow. Moreover, using TEEs effectively typically requires manually partitioning applications into enclave and non-enclave components, a process that is labor-intensive, error-prone, and lacks fine-grained control.
  We address these challenges with a three-step approach. First, we formalize SIR, an enclave-oblivious calculus based on LLVM IR, equipped with a novel permissive type system that enforces security against low-level attackers. To obtain meaningful guarantees, SIR combines information-flow control with security-aware coarse-grained memory safety. Second, we extend SIR to SIREN, an enclave-aware calculus that enforces noninterference against stronger attackers capable of observing arbitrary non-enclave memory. Third, we develop a type-driven, type-preserving compilation from SIR to SIREN that automatically produces secure enclave-aware programs, eliminating manual partitioning while providing fine-grained control over host-enclave boundaries.
  We implement and evaluate SPLITR on thirteen microbenchmarks and real-world workloads, including applications from SGXGauge, on Intel SGX hardware. SPLITR scales to OpenSSL (425,953 LLVM IR instructions) and supports multiple objectives that expose trade-offs among enclave TCB size, host-enclave transitions, and boundary data movement. For OpenSSL, optimizing for transitions reduces them from 393 to 187. Runtime overhead is dominated by fixed enclave costs for short-running workloads, whereas long-running applications better amortize these costs and approach native performance.</summary>
    <category term="cs.CR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-02T03:25:29Z</published>
    <arxiv:primary_category term="cs.CR"/>
    <author>
      <name>Wesley B. Nuzzo</name>
    </author>
    <author>
      <name>Samuel Dodson</name>
    </author>
    <author>
      <name>Benjamin Houle</name>
    </author>
    <author>
      <name>Tarakaram Gollamudi</name>
    </author>
    <author>
      <name>Anitha Gollamudi</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2609.01771v1</id>
    <title>GadIR: A Spatial-Topology Preserving Compiler for Quantum Many-Body Systems Simulation</title>
    <updated>2026-09-01T18:42:13Z</updated>
    <link href="https://arxiv.org/abs/2609.01771v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.01771v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Simulating quantum many-body systems has been one of the most important applications of quantum computation. For simulation, the Hamiltonian of a physical system is compiled into quantum programs with native instructions for quantum hardware. In previous works, the Hamiltonian is represented as Pauli strings, then compiled and optimized based on the quantum circuit model. Such representation paradigm neglects the spatial topology of original physical models, which is vital information to reducing the overhead of compiling many-body systems Hamiltonians.
  To address such neglect, we introduce a spatial-topology preserving compiler for quantum many-body simulation. Using Pauli gadgets as the representations of the Hamiltonian, we introduce our intermediate representation -- GadIR, to preserve the spatial-topology information of original physical models. Our compiler frontend performs the group reduction algorithm based on Pauli gadget model, which is a hardware-independent optimization. Our compiler backend performs trotterization and scheduling on Pauli gadgets, then synthesizes the Pauli gadgets into hardware-native quantum programs. We evaluate our compiler on all the canonical quantum many-body system models, while achieving a significant reduction on compilation overhead regarding four major quantum architectures. Overall, our spatial-topology preserving IR exploits the compilation optimization space for quantum many-body systems Hamiltonian.</summary>
    <category term="quant-ph" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-01T18:42:13Z</published>
    <arxiv:comment>59th IEEE/ACM International Symposium on Microarchitecture (MICRO 2026)</arxiv:comment>
    <arxiv:primary_category term="quant-ph"/>
    <author>
      <name>Xiangyu Ren</name>
    </author>
    <author>
      <name>Yuexun Huang</name>
    </author>
    <author>
      <name>Zhaohui Yang</name>
    </author>
    <author>
      <name>Yuchen Zhu</name>
    </author>
    <author>
      <name>Tsung-Wei Huang</name>
    </author>
    <author>
      <name>Tsung-Yi Ho</name>
    </author>
    <author>
      <name>Zhiding Liang</name>
    </author>
    <author>
      <name>Antonio Barbalace</name>
    </author>
  </entry>
</feed>
