cs.PLAug 28, 2025

CrossTL: Hub-Based Translation of GPU Programs and the Preservation of Source Rules

Authors: NRIPESH NIKETAN, VAATSALYA SHRIVASTVA, BHUSHAN SRIVASTAVA, SUSHANT MISHRA

Abstract

GPU programs are written in vendor languages that disagree about integer overflow, division by zero, NaN handling, floating-point contraction, data layout and dispatch, so a translated program can compile and still compute something else. We describe CrossTL, an open-source translator that routes ten GPU source languages to eleven targets through CrossGL, a textual hub language, with repository-scale porting, contracts that loaders check, and native parity tests. We define faithful translation as refinement up to rejection under a compile configuration, and test whether a hub that records each source rule and lowers it through one per-target table keeps rules that a syntax-only hub loses. On an internally pre-registered suite of 66 hazard kernels in six languages, run on an Apple GPU through Metal, MoltenVK and WebGPU and on CPU implementations of Vulkan, OpenGL and an emulated Direct3D 12, SPIRV-Cross, naga, Tint, Slang and CrossTL each lose some source rule, and outcomes change with Metal's math mode and between two Vulkan implementations. A rule-carrying prototype of the hub removes 34 of 39 divergences on the rules it carries, against 14 for local fixes to four SPIR-V defects, and refuses where WGSL cannot express a rule. The registered hypothesis that it keeps every rule fails: MoltenVK, a non-conformant Vulkan layer, drops a rule that correct SPIR-V carries natively. On 2,585 programs written by third parties, 31% of CrossTL's translations are usable, established translators produce valid output significantly more often in 31 of 39 comparisons, and carrying the rules changes no target's accepted share by more than 0.2 points. Recording each operation's source rule suffices for the rules tested but is not necessary: one strongest rule would keep them too, at about nine times as many rewrites and 58 more refusals on the corpus.

Figures & tables

Appendix figures & tables20 assets

Supplementary material from the paper’s appendix.

Appendix

Explore similar work

Oct 5, 2026

RESOLVE: Language-Agnostic Validation of GPU Kernels Through Testing, Reduction, and Proof

AI systems can now write and optimize production GPU kernels, but validating them remains an important challenge. Evaluating the kernel on a few random inputs and checking that its outputs match a trusted reference kernel within numeric tolerances is not sufficient: races can cause nondeterministic behavior that fails to manifest in tests, and numeric tolerances can hide bugs and cause false positives even after extensive calibration. To address this challenge, we present RESOLVE, which combines testing and formal verification to build a comprehensive kernel validation pipeline. It operates in three steps: First, it tests for nondeterminism using binary instrumentation that perturbs execution timing to expose races. Second, an agent rewrites the candidate and reference kernels to obtain "reduced-concurrency" versions that are simpler to analyze but still produce bitwise-identical outputs in all tests. Third, the reduced kernels are formally analyzed in the F*/Pulse framework and prove that they perform the same computation on real numbers. This sidesteps the need for numeric tolerances. We show that RESOLVE can validate a broad selection of kernels using KernelBench, and prove equivalence across fused GEMMs in three state-of-the-art frameworks and languages: CUTLASS, Triton, and Gluon. It also analyzes mega-kernels, notoriously difficult to validate, and finds four previously unreported issues, including two clear bugs. We show that agents can use RESOLVE to repair the issues, with minimal performance impact, highlighting that agents can optimize aggressively when they can rigorously check their results.
Aug 8, 2026

What Irregularity Costs: CUDA C++, Rust, and Triton on a Hash-Blocked GPU Workload

GPU language comparisons are almost always run on tiled dense linear algebra, where every toolchain is good and the differences are small. We implement the same hash-blocked TSDF fusion kernel in CUDA C++, in Rust through NVIDIA's cuda-oxide, and in Triton, and measure it on a workload with the opposite character: an open-addressed hash table with compare-exchange insertion, data-dependent per-lane probe depth, and contended scatter. The result is a split. On the regular stage, which walks a truncation band and accumulates, all three languages land within a small factor of each other. On the irregular stage, which probes and inserts, Rust stays close to hand-written CUDA C++ while Triton is more than an order of magnitude slower. Language choice is nearly free on the work that is usually benchmarked and expensive on the work that is not. We attribute both gaps to specific things the languages cannot express, not to ratios. Triton's cost follows from a probe loop that must run to a compile-time bound and from tl.atomic_cas taking no mask, which forces a scratch structure with no counterpart in CUDA. Rust's cost was invisible in every instruction count: its kernel issues fewer instructions, fewer compare-exchanges and fewer registers at identical occupancy, yet was slower. Hardware counters located it in L1 residency. A GPU-scope atomic load must be coherent across SMs, no NVIDIA L1 is, so the type-correct way to read a shared location bypasses the cache on every access. Triton's bounded probe is also a correctness problem for fusion: at load factors an ordinary depth trajectory reaches, it silently discards blocks and the reconstruction loses patches of surface with nothing reported. We also report a defect found and fixed in cuda-oxide itself, now merged upstream: its scoped atomic load and store could not be called at all in the build mode that produces real kernels.
Oct 4, 2026

MetaKernelBench: Measuring GPU Kernel Knowledge Transfer Beyond Code

Recent GPU kernel optimization agents retain what they learn in knowledge bases or as distilled skills. Kernel benchmarks score each attempt's implementation for correctness and speed but leave the reuse value of retained experience unmeasured. We introduce MetaKernelBench, which measures whether experience distilled from an attempt in one kernel domain-specific language (DSL) improves a fresh attempt at the same problem in another. Its 74 problems are fused subgraphs in six families, each posed as a pair of CuTe DSL and TIRx variants that differ only in the DSL. The agent first attempts each variant solo and is instructed to distill what it learns into a natural-language skill, which is transferred whether or not the source attempt passes verification. The skill is the only extra input to a skill-conditioned attempt by the same model in the other DSL. We compare each skill-conditioned attempt with the solo attempt on the same variant under matched per-attempt budgets, scoring correctness and end-to-end runtime. Across six models and both directions, paired lift over solo attempts ranges from -19% to +29%. Four models gain in both directions, yet regressions occur on 16% to 45% of problems in every model and direction. Outcomes follow the source attempt's result relative to the target's solo attempt rather than source success alone, improving in 71% of comparisons when the source stands above and regressing in 54% when it stands below. MetaKernelBench complements implementation-quality metrics by measuring same-problem cross-DSL kernel knowledge transfer.