F INDING C OMPILER -P LATFORM I NTERACTION B UGS IN D EEP L EARNING P IPELINES VIA C ROSS -L AYER C ONSTRAINTS
arXiv:2606.18421v1 [cs.SE] 16 Jun 2026
Yuxin Qiu* 1 , Jiyuan Wang2 , Ronak Badhe3 , Ben Limpanukorn3 , Miryung Kim3 , Qian Zhang1 1 UC Riverside 2 Tulane University 3 UCLA
A BSTRACT The growing deployment of artificial intelligence (AI) necessitates robust deep learning (DL) compilers, such as TVM and ONNX-MLIR. These compilers take as input high-level AI models, lower them through multi-layer transformations, and specialize them to diverse hardware. Testing such compilers is uniquely challenging as correctness depends on implicit constraints embedded throughout the compilation stack. Existing testing approaches largely take type constraints to restrict input model generation and therefore emphasize type validation and monitor compilation crashes or coverage gains. This focus overlooks compiler-platform interaction bugs that arise from interleaved effects across compilation and execution environments. In this work, we propose a scalable, automated DL compiler testing framework for, in tandem, (1) finding compiler-platform interaction bugs and (2) enabling behavior equivalence partitioning. Our key insight is that these bugs are caused by violated assumptions arising from interactions across compilation passes and hardware platforms. Therefore, we move beyond constraining input generation and derive full-stack constraints. Our approach is three-fold. First, we design an automated approach to extract full-stack constraints that jointly guide model generation and characterize compilation behaviors. Second, we prioritize constraints that expose interaction-sensitive behaviors, so our generated models are capable of exercising deep compilation logic. Third, we enable behavior equivalence partitioning by automatically inserting assertions to monitor distinct compilation symptoms that coverage or pass/fail signals miss. We evaluated our tool, XC HECK, on three widely-used DL compilers and found 2,034 bug-revealing cases, including memory overflows, integer overflows, and silent unexpected compilations that were rooted in compiler-platform interactions.
1
Introduction
The rapid integration of artificial intelligence (AI) models into critical domains necessitates reliable system deployment. Deep learning (DL) compilers serve as the backbone of this process. These compilers, such as TVM [Chen et al.(2018)], TensorRT [ten(2026)], ONNX-MLIR [Jin et al.(2020)], and GeneSys [Ghodrati et al.(2024)], deploy deep neural network (DNN) models across various hardware platforms, including GPUs, FPGAs, and specialized accelerators. They optimize DNN models by (1) transforming them into intermediate representations (IRs) and (2) applying a series of compilation passes on IRs to optimize performance and resource utilization. For example, GeneSys [Ghodrati et al.(2024)] converts a DNN model represented in ONNX [onn(2026c)] into a high-level IR called f-DFG [Ghodrati et al.(2024)], which is then mapped to a lower-level IR called codelet [Ghodrati et al.(2024)]. This codelet representation further goes through several compilation passes that optimize it based on hardware characteristics such as memory size, bandwidth, and computational capabilities. The optimized codelet is compiled into executable instructions for the target hardware. Current Practices. Testing DL compilers typically centers around generating DNN models [Liu et al.(2023a), Xie et al.(2022), Wang et al.(2024), Zhou et al.(2024)]. Although existing approaches differ in how models are generated, they largely follow the common pattern of encoding type-validity constraints or equivalence-preserving rules/con∗
Corresponding email: [email protected].
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Input Space
Operator Constraints as Shields
Input Check
Transformation
Existing Approaches (E.g., [23][38])
XCheck
Compiler-Platform Interaction Bugs
DL Compiler Compilation Stages
Full-Stack Constraints
Target Codegen
Part 2: Deep Compilation Exploration CoarseGrained Oracles
Diverse Behaviors
Part 3: Behavior
DL Compiler Generated Test Inputs
Input Check
Execution Monitoring
Differentiation
Late Stages
Transformation
Transformation Invariants
Least Exercised Logic
Codegen
Resource Feasibility
Extracted Full-Stack Constraints
FineGrained Oracles
Part 1: Automated Stack-Wise Constraint Extraction AST Parsing
(a) Existing Approaches v.s. XCheck
Pattern Matching
(b) XCheck Architecture
Figure 1: Overview of XC HECK. Unlike existing approaches [Liu et al.(2023a), Liu et al.(2023b), Wang et al.(2023), Ma et al.(2023), Deng et al.(2022), Mu et al.(2025)] that restrict inputs with local operator-level constraints and rely on coarse-grained pass/fail oracles, XC HECK extracts full-stack constraints (Section 3.1) to both drive deep compilation exploration (Section 3.2) and enable behavior equivalence partitioning (Section 3.3). straints. Next, they detect issues via coarse pass/fail signals [Liu et al.(2023a), Liu et al.(2023b), Deng et al.(2022)] or differential mismatches [Ma et al.(2023), Mu et al.(2025), Zhou et al.(2024)]. In both cases, constraints mainly shape the input space, leading to three key limitations. First, constraining input space mainly exercises front-end validation, but severe compiler bugs often arise from interactions between compiler decisions and platform-specific constraints during optimization, memory planning, or hardware-specific lowering. A recent study [Yu et al.(2026)] reports that bugs in DL compilers can emerge across the stack, which spans input model validity checks, multi-layer compilation and optimization, and target hardware, with over 70% bugs caused by compiler’s specific deployment context rather than input models only. This strongly suggests that testing must capture end-to-end correctness properties, not just model legality. Second, not all constraints are equally effective in exposing compiler-platform interactions. In fact, most constraints only gate early compilation stages, such as parsing and type checking. As a result, testing is often biased toward early inputlevel failures rather than stressing later stages where platform-specific behaviors emerge, such as layout transformation or target-specific code generation. Our experiments showed that 65% of generated models in [Liu et al.(2023b)] were rejected by GeneSys before entering lowering passes. Third, existing DL compiler testing lacks fine-grained oracles to distinguish semantically different compilation behaviors beyond crashes or output mismatches. These coarse signals are insensitive to silent correctness violations. In our study, 1,022 test cases for GeneSys completed compilation and produced outputs normally. However, 691 of them silently encountered memory overflows during tensor allocation, where integer overflows were triggered during size computation without any warnings or failures. Despite normally producing outputs, these executions violated different correctness assumptions and represented distinct compilation behaviors that are invisible to crash, coverage, or output-based oracles. XC HECK.
We propose to lay the groundwork for establishing correctness foundations for DL compiler testing. Specifically, we propose XC HECK, a DL compiler testing framework that uses cross-layer constraints to check the correctness of compiler-platform interactions. Our key insight is that full-stack constraints are enablers for both (1) exposing compiler-platform interaction bugs and (2) partitioning compilation behaviors into equivalence classes. The novelty of XC HECK is that rather than naïve constraint-based generation, it treats cross-layer constraint satisfaction and violation as observational signals to expose interaction-sensitive compiler behaviors and to induce behavior partitioning. This allows us to distinguish deep compilation behaviors even when executions uniformly succeed or fail. Our key approach is three-fold.
Part 1. Automated and Scalable Full-Stack Constraint Extraction. We automatically extract full-stack constraints spanning model semantics, compilation transformations, and hardware feasibility. This process combines (1) rule-based pattern matching, (2) AST-level parsing over compiler artifacts, and (3) cross-referencing for validation. Thus, the resulting constraints go beyond local operator validity and reflect cross-layer correctness properties. The constraint extraction process is scalable and readily generalizable across compilers and hardware backends.
2
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Part 2. Constraint-Enabled Deep Compilation Exploration. To detect compiler-platform interaction bugs, we leverage the extracted constraints to steer exploration into under-exercised parts of the compiler. XC HECK’s first goal is to generate input models that are capable of reaching late compilation stages where platform-specific behaviors are exercised. Therefore, it dynamically memorizes the latest stage that each model reaches and prioritizes ➊ constraints that can expose interaction-sensitive failures. Its second goal is to generate input models that are capable of finding new unseen bugs. Therefore, it prioritizes ➋ constraints that are least frequently used at the same stage to increase diversity in compilation behaviors. Part 3. Constraint-Enabled Behavior Differentiation. XC HECK differentiates compilation behaviors by partitioning compilations into equivalence classes based on full-stack constraints. The rationale is that constraints encode internal compilation assumptions, and equivalent behaviors share the same satisfaction/violation patterns. Thus, we convert the constraints into explicit behavioral invariant checks and insert them as assertions around compilation passes. These assertions provide behavioral indicators that existing pass/fail or coverage metrics cannot capture. Results. We extensively conducted an evaluation on three commonly used DL compilers: TVM [Chen et al.(2018)], ONNX-MLIR [Jin et al.(2020)], and GeneSys [Ghodrati et al.(2024)]. We identified 2,034 new cases that exposed bugs in target compilers, and they were further classified into three unique new bug types : memory overflows, integer overflows, and silent unexpected compilation. In summary, this work makes the following contributions. • XC HECK is the first DL compiler testing framework that leverages full-stack constraints to target compiler-platform interaction bugs missed by existing work. The constraint extraction process is automated and readily generalizable. • XC HECK detected 1,022 new bugs for GeneSys, 821 for ONNX-MLIR, and 191 for TVM. • XC HECK enables partitioning of behavior equivalence by taking constraints satisfaction and violations as observational signals. Such abstraction applies to other staged systems where internal semantic checkpoints provide richer behavioral signals.
2
Background
2.1
DNN Models and DL Compilers
DNN models are directed graphs of tensor operators that process input tensors to generate output tensors. DL compilers translate DNN models into executable code for target hardware platforms. While there exist various DL compilers, they typically follow a common compilation flow. For example, compilers that take ONNX-formatted models [onn(2026c)], including TVM [Chen et al.(2018)], ONNX-MLIR [Jin et al.(2020)], and GeneSys [Ghodrati et al.(2024)], broadly include three stages: • Input Validity Check: This stage checks the correctness of input ONNX models by verifying input/operator compatibility. For example, TVM first validates the basic structure of the input model. If the model fails validation, the compilation is terminated; otherwise, TVM converts the model into a graph-level IR called Relay for further optimization. • Multi-Layer IR Optimization: This stage transforms the input model into various IRs by applying high- and lowlevel transformations. High-level transformations restructure computation graphs which is often hardware-agnostic, while low-level transformations optimize execution for specific hardware targets [Shen et al.(2021)]. • Target Code Generation: This stage converts the optimized IR into hardware-specific code for execution on target backends, such as GPUs, FPGAs, and other specialized accelerators. 2.2
Target Hardware Platforms
IR optimizations in DL compilers are often coupled with target hardware, which offers different execution paradigms [Fowers et al.(2018), Xu et al.(2023), Chen et al.(2016)]. Single Instruction, Multiple Data (SIMD) [Fowers et al.(2018), Chen et al.(2016)] applies the same operation on multiple data points simultaneously. Systolic arrays [Xu et al.(2023), Das et al.(2020), Genc et al.(2021), Kung et al.(2019), Lym and Erez(2020)] optimize matrix operations by streaming data through processing elements in a synchronized manner, which requires careful alignment between data and hardware. As shown in Table 1, high-level IR transformations, such as operator fusion to reduce memory accesses, are often hardware-agnostic. In contrast, low-level IR optimizations are applicable to different hardware targets. For example, padding ensures proper computation and memory alignment on systolic arrays, whereas SIMD architectures typically rely on vectorized loads and masked execution to handle boundary conditions without explicit padding. 3
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Hardware
Table 1: IR Optimization and Hardware. High-Level IR Transformation Low-Level IR Transformation Operator Fusion Loop Unrolling Tiling Padding
SIMD
✓
✓
✓
Systolic Array
✓
✓
✓
✓
Table 2: Examples of Extracted Constraints. Category
Example Graph Topology
Generative Guidance
Algebraic Semantics Operator Parameter Bound Data Representation Legality Resource Compatibility
Behavioral Monitoring
2.3
Semantic Preservation Hardware Feasibility Resource Safety Transformation Correctness Execution Safety
("topo-reshape-relu-shape", ["reshape", "relu"], ["reshape-out-shape", "relu-in-shape"], "%reshape-out-shape EQUAL %relu-in-shape") ("sem-matmul-k-match", ["matmul"], ["input1-height", "input2-width"], "%input1-height EQUAL %input2-width") ("param-conv-stride-leq-kernel", ["conv"], ["stride-height", "kernel-height"], "%stride-height LEQ %kernel-height") ("dtype-abs-supported-type-only", ["abs"], ["input-dtype"], "%input-dtype IN {FXP8, FXP16, FXP32}") ("res-abs-input-size", ["abs"], ["width", "height", "data-bits", "dram-size"], "%width TIMES %height TIMES %data-bits LEQ %dram-size") "assert" OutputHeightBeforeFusionPass "==" OutputHeightAfterFusionPass "assert" TensorWidth "%" SystolicArrayM "==" "0" "assert" TensorSize "<=" DeviceMemory "assert" TensorWidth "%" TileWidth "==" "0" "assert" RuntimeState "!=" "ILLEGAL"
Testing DL Compilers
We briefly describe the key components in testing DL compilers. • Input Model Generation: Testing DL compilers requires systematically generated DNN models to exercise diverse compilation behaviors. Various model generators have been created that analyze syntactic and/or semantic validity constraints at the model or tensor level. They generate both valid models (which conform to type constraints) and invalid models (which intentionally violate constraints) to test compiler behaviors. For example, NNSmith [Liu et al.(2023a)] generates valid models by ensuring compatible tensor shapes, data types, and operator attributes, while it generates invalid models by violating these constraints. • Test Oracle: Prior work [Deng et al.(2022), Liu et al.(2023a), Liu et al.(2023b), Ma et al.(2023), Wang et al.(2023), Mu et al.(2025)] primarily relies on crash-based oracles and monitors coverage. Another commonly used oracle [Ma et al.(2023), Liu et al.(2023a), Liu et al.(2023b)] takes models validity as the criterion: valid models are expected to compile, while invalid models should be rejected with an appropriate exception. Under this oracle, a compiler issue is reported if a valid model fails to compile or an invalid model is accepted without error. Our extensive investigation of representative DL compilers [Ghodrati et al.(2024), Jin et al.(2020), Chen et al.(2018), ten(2026), glo(2026), Abadi et al.(2016), Paszke et al.(2019)] and model generation techniques [Xie et al.(2022), Liu et al.(2023a), Liu et al.(2023b), Ma et al.(2023), Wang et al.(2023), Mu et al.(2025), Deng et al.(2022)] reveals three key observations. Observation 1: Type-valid input models do not always lead to successful compilation and hardware execution. For example, the GeneSys compiler [Ghodrati et al.(2024)] crashed while allocating FPGA memory for a valid model with tensor shapes (1, 16, 10048934087, 22145136773). The failure occurred because the memory required for tensor allocation exceeded the available DRAM capacity. This suggests that compiler-platform interaction bugs cannot be exposed by input validity alone, but require considering platform-specific constraints across the compilation stack. Therefore, testing needs to incorporate such constraints when generating input models. Observation 2: Full-stack constraints can be mined but are largely overlooked in testing. Prior work has shown that DNN operator constraints can be mined from model specifications and documentation [Liu et al.(2023a), Xie et al.(2022)]. We also observe that compilation- and hardware-related constraints are generally embedded in compiler documentation, compiler source code, and hardware specifications. For example, ONNX-MLIR [Jin et al.(2020)] implementation defines that the tiling factor for an input model should be a multiple of the SIMD vector size, which 4
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
A. ONNX Documentation Abs
B. Pattern Matching Rules
- Name: Abs - since_version: 13
<letter>*
Summary
(- <letter>+ ((<letter>*))? - T<digit>*: <letter>*)+
<operator> Inputs
Absolute takes one input data (Tensor) and produces one output data (Tensor) where absolute value, y = abs(x), is applied to the tensor elementwise.
Outputs (- <letter>+ ((<letter>*))? - T<digit>*: <letter>*)+
Type Constraints
Inputs
(- T<digit>* in ((tensor(<letter>+<digit>*))+))+
- X (heterogeneous) - T: Input tensor
Outputs
C. Parsing Results
- Y (heterogeneous) - T: Output tensor
Operator: Abs # of Input Tensors: 1 # of Output Tensors: 1 Tensor Type: double, float, int32
Type Constraints - T in (tensor(double), tensor(float), tensor(int32))
Figure 2: Constraint Extraction from Documentation. can be obtained from hardware specifications. Despite their importance, existing testing approaches focus only on operator-level constraints, leaving many overlooked. Observation 3: Existing testing oracles are coarse-grained and fail to differentiate compiler behaviors beyond crashes or acceptance, while constraints naturally define finer-grained outcome oracles. In fact, many correctness issues do not manifest as explicit signals such as crashes or rejections. For example, in our experiments, GeneSys silently compiled models with unsupported data types without reporting any error. In the end, it produced executables that computed incorrect results without any error signals. Such behaviors violate implicit expectations, such as type support and transform invariants, but remain invisible under coarse-grained oracles. Based on these observations, we conclude that testing DL compilers requires analyzing constraints across the stack, which goes beyond type validity at the input model level. These observations form the foundation of XC HECK’s full-stack constraint extraction procedure, detailed in Section 3.
3
XC HECK
XC HECK focuses on DL compilers that take ONNX-formatted DNN models as input. It is general because it is readily
extensible to new hardware backends and compilers with lightweight configuration. As shown in Figure 1(b), it extracts constraints to capture full-stack insights (Section 3.1), leverages the extracted constraints as model generative guidance to drive testing into interaction-sensitive stages (Section 3.2), and also differentiates compilation behaviors through compilation behavioral monitoring (Section 3.3). In this paper, we refer to compiler-platform interaction-sensitive stages as late compilation stages with deep compiler logic, where compiler decisions are coupled with platform-specific constraints, such as memory planning and hardwarespecific lowering. 3.1
Scalable Constraint Extraction
As shown in Table 2, the extracted constraints are classified into two categories: (1) model generative guidance to generate input models for meaningfully exercising the compiler, as discussed in Section 3.2; and (2) compilation behavioral monitoring to enable behavior equivalence partitioning, as discussed in Section 3.3. Step 1: Pattern Matching in Documentation. We observe that (1) cardinality, type, and resource constraints are explicitly defined in documentation, including ONNX documentation, compiler documentation, and hardware specifications, and that (2) such documentation follows a consistent structure. Figure 2A shows the description of ONNX operator Abs [onn(2026a)]. It begins with the operator name and version ID, followed by a summary and three structured sections: Inputs, Outputs, and Type Constraints, which specify expected tensor properties. Other operators in ONNX documentation [onn(2026b)] follow the same structure. We encode pattern matching rules for each kind of documentation. Take ONNX documentation as an example. In Figure 2B, we identify the operator name using the pattern <operator> <letter>* . The Inputs and Outputs sections are parsed using (-<letter>+((<letter>*))? - T<digit>*: <letter>*)+ , which captures the input 5
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
1 2 3 4
ArrayHeight -> ExtArrayHeightKey "=" Number ArrayWidth -> ExtArrayWidthKey "=" Number DataSize -> ExtDataSizeKey "=" Number Bandwidth-> ExtBandwidthKey "=" Number
5 6 7 8 9
ExtArrayHeightKey -> "ARRAY_M" | ... ExtArrayWidthKey -> "ARRAY_N" | ... ExtDataSizeKey -> "DATA_WIDTH" | ... ExtBandwidthKey -> "IBUF_CHANNEL_BW" | ... (a) Rule Template for Hardware Specifications.
1 2
PaddingFactor -> VarName “=” PFCall PFCall -> ExtPadFactorOpName “(“ VarName “,” VarName “)”
3 4 5 6
NewTenshorShape -> VarName “=” PadCall PadCall -> ExtPadOpName “(“ VarName “,” VarName “)”
7 8 9 10
ExtPadFactorOpName -> "lcm" | ... ExtPadOpName -> "pad_fn" | ... (b) Rule Template for Compilers.
1
ArraySize -> ArrayHeight "*" ArrayWidth
2 3 4 5
PaddingFactorConstraint -> “assert” PaddingFactor “%” Bandwidth “==” “0” “assert” PaddingFactor “%” ArraySize “==” “0”
6 7 8 9 10
NewTensorWidthConstraint -> “assert” NewTensorWidth “%” PaddingFactor “==” “0” NewTensorHeightConstraint -> “assert” NewTensorHeight “%” PaddingFactor “==” “0” (c) Conditions as Guards for Padding.
Figure 3: Example of Assertions to Insert. and output tensor properties. For example, to extract the input cardinality constraint, we count the occurrences of the pattern - <letter>+ ((<letter>*))? - T<digit>*: in Inputs section in Figure 2A, which is 1. Figure 2C shows the pattern matching results of Abs: the number of input tensors and output tensors should be both 1; the tensor type should be double, float, or int32. As another example shown in Figure 3a, to extract the constraint on hardware resources (e.g., systolic array size) from hardware specifications, we define the rule templates in Lines 1–4 that are concretized with compiler-specific keywords, such as ARRAY_M in Line 6 and ARRAY_N in Line 7 for GeneSys. We use nonterminals that start with Ext, as highlighted in blue, to define what keywords to match. They are extensible to other compilers by incorporating more keywords used in hardware specifications. For example, we retrieve the height of the systolic array using ArrayHeight -> ExtArrayHeightKey “=” Number in Line 1, where ExtArrayHeightKey abstracts the specific keyword denoting the array height. This nonterminal can be instantiated with ARRAY_M for GeneSys, with meshX for compilers that consume Timeloop-style architecture specifications [Parashar et al.(2019)], or with other corresponding keywords used in hardware specifications. This allows the rule to be adapted for other compiler documentation. Step 2: AST Parsing in Implementation. Constraints for compilation behavioral monitoring mainly come from compiler implementation and therefore reflect the actual compiler behaviors. As shown in Table 2, they encode pass-level invariants, such as semantic preservation and hardware feasibility, that should be evaluated before and after individual compilation passes. We thus use the extracted constraints to form compilation guards, which should not 6
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Algorithm 1: Constraint-Guided Model Generation Input: P = {(ci , ri , ui )|1 ≤ i ≤ n}: the operator constraint coverage information, which includes the rank, ri , for constraint ci , as well as the number of usage times, ui , that ci has been prioritized to violate Output: P ′ = {(ci , ri′ , u′i )|1 ≤ i ≤ n}: the updated constraint coverage information 1 begin 2 P s ← find_smallest_rank(P ) 3 if P s has size 1 then 4 ck , rk , uk ← get_element(P s) 5 else 6 ck , rk , uk ← find_least_frequently_used(P s) 7 end 8 C ← {c1 , c2 , · · · , ck−1 , ¬ck , ck+1 , · · · , cn } 9 M ← generate_model(C) 10 Compile M and record the number of completed compilation passes as p 11 rk′ ← rk + 1/p 12 u′k ← uk + 1 13 P′ ← P 14 In P ′ , update (ck , rk , uk ) to (ck , rk′ , u′k ) 15 return P ′ 16 end
be violated. We analyze four target IR optimizations in Table 1 and define rule templates for each hardware-related optimization. Such templates are easily extensible to other compilers. • Tiling: The tile size should be a factor of the original tensor size to ensure memory partitioning. • Padding: The padding factors should align with the hardware for efficient computation. • Loop Unrolling: The unrolling factor should be a factor of the loop size to preserve correctness in iteration expansion. • Operator Fusion: The output of one operator must be directly usable as input to the next operator to enable fusion. For example, padding typically involves computing ➊ a padding factor A followed by determining ➋ the padded tensor shape B. We need to check if B is a multiple of A and if A aligns with ➌ the hardware systolic array C (e.g., height and width), which has already been extracted from Figure 3a based on hardware specification. Figure 3b shows the rule template for extracting padding factor A and padded tensor shape B based on function names ExtPadFactorOpName (Line 9) and ExtPadOpName (Line 10) in compiler implementation. Such nonterminals starting with Ext, as highlighted in blue, define compiler-specific keywords to search in ASTs, and they are extensible to other compilers by incorporating compiler-specific function names as padding locations. For example, padding in TVM is implemented in function padding_2d_nhwc_fp1. To extract compilation guards for TVM, we can simply add padding_2d_nhwc_fp1 as a new terminal for ExtPadOpName in Line 10. Now we showcase how this rule template works with GeneSys. GeneSys calculates the padding factor in function lcm (Line 9). Therefore, XC HECK concretizes Line 2 and Line 9 as PFCall -> ExtPadFactorOpName “(” VarName “,” VarName “)” ExtPadFactorOpName -> “lcm” | ...
.
XC HECK then parses GeneSys ASTs to identify the function call to lcm and retrieves its return value as the padding factor. Similarly, since GeneSys computes the padded tensor shape in function pad_fn (Line 10), XC HECK derives the
following rules. PadCall -> ExtPadOpName “(” VarName “,” VarName “)” ExtPadOpName -> “pad_fn” | ...
This guides XC HECK in locating the function call pad_fn in ASTs. Additionally, in step 1, XC HECK has already retrieved hardware specifications such as ARRAY_M, ARRAY_N, and DATA_WIDTH in Figure 3a. Finally, XC HECK constructs compilation conditions to validate the padding strategy implementation, as shown in Figure 3c. For example, the condition “assert” PaddingFactor “%” Bandwidth “==” “0” checks if the padding factor is aligned with the bandwidth.
7
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
C2 2 0 2 0 2.25 1 2.25 1 2.5 2 2.75 3 3 4 3 4
Table 3: Working Example of Constraint Guidance. C3 Criterion Selected Constr. Actions 3 Violating C1 leads to a failure after pass 1. Smallest Rank C1 0 Update C1 rank: 1 + 1 / 1 = 2 3 Violating C2 leads to a failure after pass 4. LFU C2 0 Update C2 rank: 2 + 1 / 4 = 2.25 3 Violating C1 leads to a failure after pass 1. Smallest Rank C1 0 Update C1 rank: 2 + 1 / 1 = 3 3 Violating C2 leads to a failure after pass 4. Smallest Rank C2 0 Update C2 rank: 2.25 + 1 / 4 = 2.5 3 Violating C2 leads to a failure after pass 4. Smallest Rank C2 0 Update C2 rank: 2.5 + 1 / 4 = 2.75 3 Violating C2 leads to a failure after pass 4. Smallest Rank C2 0 Update C2 rank: 2.75 + 1 / 4 = 3 3 Violating C3 leads to a failure after pass 3. LFU C3 0 Update C3 rank: 3 + 1 / 3 = 3.3 3.3 Violating C1 leads to a failure after pass 1. LFU C1 1 Update C1 rank: 2 + 1 / 1 = 3
Constraint Representation.
Constraints that serve as the model generative guidance are represented as
Iter 1 Iter 2 Iter 3 Iter 4 Iter 5 Iter 6 Iter 7 Iter 8
Constr. Rank Count Rank Count Rank Count Rank Count Rank Count Rank Count Rank Count Rank Count
C1 1 0 2 1 2 1 3 2 3 2 3 2 3 2 3 2
("identifier", ["op1",...], ["arg1",...], "relation") , where each constraint has a unique identifier, ap-
plies to a specific list of operators, and defines relationships among the arguments of interest. For example, the constraint ("topo-reshape-relu", ["reshape", "relu"], ["reshape-out-shape","relu-in-shape"], "%reshape-out-shape EQUAL %relu-in-shape")
means when Reshape operator is immediately followed by Relu operator, the shape of Reshape’s output tensor should be the same as the shape of Relu’s input tensor. Constraints that serve as the compilation behavioral monitoring are represented as "assert" followed by a predicate that enforces a required condition, which are then inserted into the target compiler. For example, for correct tiling, the tile width should be a factor of the tensor width, which is represented as "assert" TensorWidth "%" TileWidth "==" "0" . Extensibility. XC HECK is automated. Its constraint extraction is generalizable across hardware targets and DL compilers. Specifically, XC HECK treats extensibility as a configuration problem: adapting to a new target requires only lightweight specification of data sources and keywords, while constraint extraction and assertion injection are performed automatically. XC HECK can also be extended to incorporate additional rules from domain knowledge or hardware insights. In Section 4.2, we evaluate XC HECK’s extensibility in detail. 3.2
Deep Compilation Exploration
Testing DL compilers needs both valid and invalid test inputs [Liu et al.(2023a), Liu et al.(2023b), Xie et al.(2022)]. While valid models satisfy all constraints, generating invalid models is challenging, as it requires deciding which constraints to negate in order to induce meaningful compiler behaviors rather than trivial rejections. One straightforward approach is violating arbitrary constraints. However, not all constraints contribute equally to exposing interactionsensitive bugs, and naïvely selecting constraints to violate will mostly result in rejections at the entry of compilers. For example, models with incompatible tensor shapes are rejected during model validation, whereas models with valid shapes but invalid resource requirements can proceed to later compilation stages where platform-specific constraints are considered. We are inspired by branch guided testing to address this challenge. First, to effectively explore interaction-sensitive stages, XC HECK dynamically records the deepest compilation pass that each model can reach and prioritizes violating operator constraints that can trigger failures in later stages. Second, to reveal unseen bugs and optimize constraint coverage, XC HECK prioritizes constraints that are least frequently used at the same stage to explore diverse behaviors. Algorithm. Algorithm 1 outlines the overall constraint-guided model generation in XC HECK. Starting with the current constraint coverage information that includes the rank and usage count of each constraint (Line Input), XC HECK prioritizes a constraint to violate, generates an invalid model, and updates the coverage information based on compilation results (Line Output). First, XC HECK identifies constraints with the smallest rank value (Line 2). If only one such constraint exists, it is picked for model generation (Line 4). If multiple constraints share the smallest rank, the least 8
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Original Implementation constr = np.lcm(bandwidth, sys_dims) pad_fn = lambda shape, v: -1*(shape // (-1*v))*v dummy_inp_dim = template.node.inputs[0].shape[1] new_inp_dim = pad_fn(dummy_inp_dim, constr)
Implementation with Guard Checks constr = np.lcm(bandwidth, sys_dims) assert constr % bandwidth == 0 assert constr % sys_dims == 0 pad_fn = lambda shape, v: -1*(shape // (-1*v))*v dummy_inp_dim = template.node.inputs[0].shape[1] new_inp_dim = pad_fn(dummy_inp_dim, constr) assert new_inp_dim % constr == 0
Figure 4: XC HECK injects assertions into the compiler for compilation behavioral monitoring. frequently used (LFU) one is chosen (Line 6). Next, XC HECK uses this constraint to guide the model generation. After that, XC HECK uses the target compiler to compile the generated model and records the number of compilation passes completed before a failure, which is denoted as p (Line 10). The rank r of the prioritized constraint is then updated to r + 1/p (Line 11), ensuring that constraints triggering failures in later interaction-sensitive stages receive a smaller rank value and thus are prioritized in subsequent testing iterations. Finally, the updated coverage information is returned for subsequent testing (Line 11-15). XC HECK terminates until it reaches a time limit or all constraints have been explored. An execution of Algorithm 1 is shown in Table 3, where XC HECK needs to prioritize an operator constraint from C1, C2, and C3. Initially in iteration 1, C1 has the smallest rank, which is 1, so XC HECK prioritizes it and generates a model accordingly. This model is rejected immediately after the first compilation pass, so XC HECK updates C1’s rank to 2. Next, C1 and C2 share the smallest rank, but C2 has never been used, so XC HECK prioritizes C2. The generated model fails after four compilation passes, so XC HECK updates C2’s rank to 2.25. Iterations 3 to 6 follow the same procedure that prioritizes the constraint with the smallest rank. After that, all constraints have the same rank, but C3 remains unused, so in iteration 7, XC HECK prioritizes C3. In this way, based on dynamically updating constraint coverage information, XC HECK applies constraint-guided model generation to drive testing into interaction-sensitive stages. 3.3
Behavior Differentiation
Existing DL compiler testing approaches rely on coarse-grained signals (e.g., crashes) to distinguish compilation behaviors. However, these signals often collapse distinct behaviors into the same observable outcome. For example, a compilation iteration may fail due to resource infeasibility or incorrect parameter computation, yet both manifest as the same crash at the backend lowering stage when allocating buffers. Similarly, coverage-based metrics, such as branch coverage or compilation pass coverage, treat executions as equivalent as long as they reach the same code regions or exercise the same passes, but do not reflect whether executions correspond to meaningfully different compiler behaviors or failure causes. XC HECK uses constraints as indicators of compiler behaviors and explicitly differentiates these behaviors by partitioning
compilation behaviors into equivalence classes through automated assertion insertion. Specifically, based on the insight that there are preconditions or postconditions for intermediate compilation passes, XC HECK integrates these conditions into compilers as guard checks by performing source-to-source transformations. For example, in Figure 4, we extract padding conditions ensuring that the padding factor should be a multiple of bandwidth and systolic array size and that the new tensor shape should be a multiple of the padding factor. XC HECK enforces these conditions by inserting assertions, as shown in Figure 4. It inserts guards (1) assert constr % bandwidth == 0 and assert constr % sys_dims == 0 to verify the padding factor is correctly computed in lcm and (2) assert new_inp_dim % constr == 0 to ensure the new tensor shape is correctly computed in pad_fn. In fact, Figure 4 also illustrates why coverage-based metrics are insufficient to differentiate meaningful compilation behaviors. In this example, two input models both execute the same padding-related compilation passes that invoke the same sequence of computations (e.g., calling np.lcm and pad_fn) and therefore traverse identical control flow paths 9
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
with identical branch and pass coverage. However, it remains unclear whether intermediate computations (e.g., the result of np.lcm) are valid. Indeed, as discussed in Section 4.1, numpy (np for short) can produce incorrect results. By inserting assertions that encode expected invariants, XC HECK distinguishes these behaviors based on whether such invariants are satisfied, even when coverage metrics cannot.
4
Evaluation Results
Our preliminary evaluation seeks to answer the following research questions. RQ1 What types of and how many bug symptoms can XC HECK uncover, compared to other DL compiler fuzzers? RQ2 How well does XC HECK ’s full-stack constraint mining generalize to new hardware platforms or compiler versions, and what effort is required? Compilers under Test. XC HECK finds bugs in the following three commonly used DL compilers. • GeneSys [Ghodrati et al.(2024)]. This is one of the most recent research efforts in deploying models onto specialized hardware. It has 16 passes dedicated to model transformation and optimization. • ONNX-MLIR [Jin et al.(2020)]. This is a comprehensive compiler with hundreds of passes that transforms a model into MLIR-based representations for further optimization on hardware backends. • TVM [Chen et al.(2018)]. This compiler deploys models onto various platforms such as CPUs, GPUs, and specialized accelerators. It performs 61 graph-level compilation passes and 58 low-level passes [Liu et al.(2023a)]. 4.1
RQ1: Bug Detection Capability
We assess XC HECK’s bug detection capability by measuring its ability to uncover diverse bug symptoms in real-world DL compilers. Following prior work [Liu et al.(2023a), Liu et al.(2023b)], we run XC HECK for four hours to generate ONNX models and compile them using the three compilers under test. For valid models, compilers are expected to complete the compilation successfully, while for invalid models, compilers are expected to reject them with appropriate error signals. Guided by constraints that go beyond the input space, XC HECK detects 691 bug-revealing cases of runtime memory overflows, 331 cases of runtime integer overflows, and 1,012 cases of silent unexpected compilation. Table 4 summarizes these three bug categories. Memory Overflows. For the 2,166 models generated by XC HECK with large input tensors, GeneSys silently accepts 691 of them without raising the expected RuntimeError during memory allocation. These models contains tensors whose sizes exceed the available DRAM capacity. For example, a model with a single Add operator should be rejected during memory allocation when its input tensors has the shape (1, 16, 302492402, 1410389859), because it violates the resource compatibility constraint ("input-size-add", ["add"], ["width1", "height1", "data-bits", "dram-size"], "%width1 TIMES %height1 TIMES %data-bits LEQ %dram-size").
However, GeneSys proceeds beyond the memory allocation stage without detecting the issue. Upon investigation, we identify the root cause as a runtime integer overflow in GeneSys during tensor size computation. Specifically, GeneSys uses numpy.prod() with int32 to compute input tensor sizes. When the true size exceeds the representable range of int32, the computation overflows and yields an incorrect but smaller value due to an unintended modulo operation. As a result, GeneSys mistakenly treats oversized tensors as memory-feasible and allows invalid models to proceed. Integer Overflows. XC HECK generates 331 models that use unsupported data types (e.g.,int4, uint64), which violate the following data representation legality constraint: (..., ..., ["type1"], "%type1 IN {FXP8, FXP16, FXP32}").
However, GeneSys silently accepts them without reporting unsupported types and produces incorrect executables. Our investigation shows that unsupported types are processed at the bit level and implicitly reinterpreted as larger integer types, which leads to silent numerical corruption without any explicit warning. For example, adding two int4 tensors [7, 5] and [1, -6] should yield [8, -1]. However, we find that their bit representations, [0110 0101] 10
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Category
Compiler
Table 4: New Bugs Found by XC HECK. Cases Bug Description
Memory Overflows
GeneSys
691
GeneSys silently accepts oversized tensors without raising the expected RuntimeError. The root cause is an integer overflow during tensor size computation. XC HECK exposes it by generating large inputs that violate resource compatibility constraints.
Integer Overflows
GeneSys
331
GeneSys silently accepts unsupported data types such as int4 and produces incorrect executables. The root cause is that unsupported types are mistakenly reinterpreted as larger integer types. XC HECK exposes it by generating models that violate data representation legality constraints.
Silent Unexpected Compilation
ONNXMLIR, TVM
1,012
ONNX-MLIR and TVM silently compile models that exceed target hardware resources. The root cause is that they do not validate target hardware resource constraints during compilation. XC HECK exposes it by generating large-input models that violate resource compatibility constraints.
and [0001 1010], are in fact packed and misinterpreted as int8 tensors, producing values [117] and [26]. The resulting computation therefore produces an incorrect output of [143]. Silent Unexpected Compilation. XC HECK generates 821 models with large input tensors for ONNX-MLIR and 191 for TVM. All of these models exceed hardware resources of the target deployment environment. For example, a model with input tensor shape (1, 16, 300000000, 16) violates the resource compatibility constraint ("input-size-sub", ["sub"], ["width1", "height1", "data-bits", "dram-size"], "%width1 TIMES %height1 TIMES %data-bits LEQ %dram-size").
However, both ONNX-MLIR and TVM accept these models and silently completed compilation without raising any warnings or errors. Our investigation shows that this behavior stems from the fact that, by default, ONNX-MLIR and TVM do not validate resource constraints of the target hardware during compilation. As a result, models that are infeasible for deployment are compiled successfully, which can subsequently lead to crashes for failures during deployment or execution. Importantly, such feasibility checks are the responsibility of compilers, as they directly determine the correctness and deployability of the generated executables. 4.2
RQ2: Extensibility
To evaluate XC HECK’s extensibility, we qualitatively and quantitatively measure how much effort is required to apply XC HECK’s existing constraint mining and behavior differentiation capabilities to a new compiler or hardware target. We report (1) categorized human effort and (2) quantitative indicators of engineering processes. Manual effort in XC HECK is limited to specifying data sources and lightweight configuration for constraint mining and assertion injection. Constraint extraction itself is fully automated. The required, minimal effort falls into the following three categories: • Effort A: One-Time for All ONNX-Based Compilers: Providing four extraction rules for ONNX documentation (Figure 2), which are summarizable in ten minutes by a graduate student. • Effort B: One-Time Per Compiler: Specifying new compiler-specific keywords (e.g., padding-related function names) in JSON files to concretize hardware-related constraints. This step is optional for closed-source compilers; XC HECK can still work using documentation and domain knowledge without such constraints. • Effort C: One-Time Per Hardware Target: Providing minimal hardware or arithmetic domain knowledge (e.g., no zero divisors), which is a standard practice in existing approaches [Wang et al.(2023)]. XC HECK then automatically extracts relevant values (e.g., from specifications and configurations) and concretizes them into constraints. Table 5 summarizes the effort when extending XC HECK from GeneSys to ONNX-MLIR and then to TVM. We report the lines of configuration or code (LOC) added for constraint mining and assertion injection, as well as the time cost spent on adapting pattern matching to new documents and parsing a new compiler codebase. 11
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Table 5: Effort Required to Extend XC HECK across Different Compilers. Extension GeneSys → ONNX-MLIR ONNX-MLIR → TVM Average
Constraint Mining 26 LOC 42 LOC 34 LOC
Assertion Injection 26 LOC 38 LOC 32 LOC
Doc Pattern Matching 0 seconds 0 seconds 0 seconds
Code AST Parsing 2.47 minutes 9.21 minutes 5.84 minutes
Overall, extending XC HECK requires a small and bounded amount of one-time effort per target. In our evaluation, adapting XC HECK from GeneSys to ONNX-MLIR and TVM requires fewer than 50 lines of updates. In contrast, the target compiler codebases consist of hundreds of thousands of lines of code (e.g., TVM has on the order of 106 LOC based on the cloc [Danial(2021)] tool), which means that the required adaptation is negligible relative to compiler sizes. In terms of the time cost, since all of the three compilers take ONNX models as input, the pattern-matching rules used for GeneSys remain directly applicable to ONNX-MLIR and TVM. Therefore, no extra adaptation of documentation-level pattern matching is required. Parsing a new compiler codebase using tree-sitter [tre(2026)] requires less than 10 minutes. Once these locations are identified, constraint extraction proceeds fully automatically, with no further manual intervention needed.
5
Related Work
Testing DL Compilers. Testing DL compilers can be broadly factorized into two categories: (1) approaches that constrain the input space to generate diverse models, and (2) approaches that apply transformations to existing models to induce behavioral differences. The main difference among the approaches in the first category lies in where the constraints are derived from [Deng et al.(2022), Liu et al.(2023a), Liu et al.(2023b), Xie et al.(2022), Deng et al.(2023), Deng et al.(2024), Wang et al.(2023), Yang et al.(2024), Shen et al.(2025)]. For example, NeuRI [Liu et al.(2023b)] infers operator constraints from execution traces and applies concolic solving to generate models that satisfy inferred relations. GenCoG [Wang et al.(2023)] introduces a DSL for developers to explicitly specify operator constraints and incrementally solves them to construct valid models. The second category adopts transformation-based techniques, where new test inputs are derived by mutating or reconstructing existing programs or models [Pham et al.(2019), Guo et al.(2021), Wang et al.(2020), Gu et al.(2022), Luo et al.(2021), Zhou et al.(2024), Ma et al.(2023), Mu et al.(2025)]. For example, PolyJuice [Zhou et al.(2024)] applies arithmetic and structural rewrite rules to construct semantically equivalent computation graphs. HirGen [Ma et al.(2023)] applies function rewrites to add wrappers in IRs, and ModelMeta [Mu et al.(2025)] generates models that have consistent outputs but different model structures and calculation logic. In contrast, we incorporate full-stack insights rather than input limitations only, and we aim to expose compiler-platform interaction bugs rather than merely increasing coverage. We systematically drive compilation into later stages and enable difference-exposing tests that surface observable symptoms of underlying bugs. Constraint-Based General-Purpose Testing. Constraints are also used for testing general-purpose compilers. For example, ISLa [Steinhöfel and Zeller(2022)] produces test inputs satisfying logical constraints expressed over a grammar. It relies on an SMT solver to systematically enforce both syntactic and context-sensitive semantic constraints. Its companion tool, ISLearn [Steinhöfel and Smytzek(2022)], infers such constraints automatically, but requires users to provide domain-specific constraint schemata in a dedicated DSL. Similarly, Fandango [Zamudio Amaya et al.(2025)] adopts a constraint-guided generation paradigm, but uses Python as a host language for manually specifying user-defined constraints. These approaches fundamentally depend on either hand-written DSL specifications or predefined templates to infer constraints. In contrast, XC HECK automatically mines constraints from documentation and the codebase, which reduces the need of manual effort. This significantly lowers the barrier to deploying constraint-guided testing on large, real-world compilers.
6
Conclusion
XC HECK is a novel testing tool for DL compilers that uniquely focuses on detecting compiler-platform interaction
bugs. Rather than constraining the input model space, it aligns full-stack constraints to steer model generation towards interaction-sensitive stages. It also enables partitioning of behavior equivalence by taking constraint satisfaction and 12
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
violations as observational signals. Such abstraction applies to other staged systems where internal semantic checkpoints provide richer behavioral signals.
References [glo(2026)] 2026. Glow. https://github.com/pytorch/glow. [ten(2026)] 2026. NVIDIA TensorRT. https://developer.nvidia.com/tensorrt. [onn(2026a)] 2026a. ONNX Abs Operator Documentation. https://onnx.ai/onnx/operators/onnx__Abs. html#l-onnx-doc-abs. [onn(2026b)] 2026b. ONNX Documentation. https://onnx.ai/onnx/operators/index.html. [onn(2026c)] 2026c. ONNX: Open Neural Network Exchange. https://onnx.ai/. [tre(2026)] 2026. Tree-sitter. https://tree-sitter.github.io/tree-sitter/. [Abadi et al.(2016)] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek G. Murray, Benoit Steiner, Paul Tucker, Vijay Vasudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. 2016. TensorFlow: a system for large-scale machine learning. In Proceedings of the 12th USENIX Conference on Operating Systems Design and Implementation (Savannah, GA, USA) (OSDI’16). USENIX Association, USA, 265–283. [Chen et al.(2018)] Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Meghan Cowan, Haichen Shen, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: an automated end-to-end optimizing compiler for deep learning. In Proceedings of the 13th USENIX Conference on Operating Systems Design and Implementation (Carlsbad, CA, USA) (OSDI’18). USENIX Association, USA, 579–594. [Chen et al.(2016)] Yu-Hsin Chen, Joel Emer, and Vivienne Sze. 2016. Eyeriss: a spatial architecture for energyefficient dataflow for convolutional neural networks. In Proceedings of the 43rd International Symposium on Computer Architecture (Seoul, Republic of Korea) (ISCA ’16). IEEE Press, 367–379. doi:10.1109/ISCA.2016. 40 [Danial(2021)] Albert Danial. 2021. cloc: v1.92. doi:10.5281/zenodo.5760077 [Das et al.(2020)] Saptarsi Das, Arnab Roy, Kiran Kolar Chandrasekharan, Ankur Deshwal, and Sehwan Lee. 2020. A Systolic Dataflow Based Accelerator for CNNs. In 2020 IEEE International Symposium on Circuits and Systems (ISCAS). 1–5. doi:10.1109/ISCAS45731.2020.9180403 [Deng et al.(2023)] Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large Language Models Are Zero-Shot Fuzzers: Fuzzing Deep-Learning Libraries via Large Language Models. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (Seattle, WA, USA) (ISSTA 2023). Association for Computing Machinery, New York, NY, USA, 423–435. doi:10.1145/ 3597926.3598067 [Deng et al.(2024)] Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. 2024. Large Language Models are Edge-Case Generators: Crafting Unusual Programs for Fuzzing Deep Learning Libraries. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 70, 13 pages. doi:10.1145/3597503.3623343 [Deng et al.(2022)] Yinlin Deng, Chenyuan Yang, Anjiang Wei, and Lingming Zhang. 2022. Fuzzing deep-learning libraries via automated relational API inference. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Singapore, Singapore) (ESEC/FSE 2022). Association for Computing Machinery, New York, NY, USA, 44–56. doi:10.1145/3540250. 3549085 [Fowers et al.(2018)] Jeremy Fowers, Kalin Ovtcharov, Michael Papamichael, Todd Massengill, Ming Liu, Daniel Lo, Shlomi Alkalay, Michael Haselman, Logan Adams, Mahdi Ghandi, Stephen Heil, Prerak Patel, Adam Sapek, Gabriel Weisz, Lisa Woods, Sitaram Lanka, Steven K. Reinhardt, Adrian M. Caulfield, Eric S. Chung, and Doug Burger. 2018. A Configurable Cloud-Scale DNN Processor for Real-Time AI. In 2018 ACM/IEEE 45th Annual International Symposium on Computer Architecture (ISCA). 1–14. doi:10.1109/ISCA.2018.00012 [Genc et al.(2021)] Hasan Genc, Seah Kim, Alon Amid, Ameer Haj-Ali, Vighnesh Iyer, Pranav Prakash, Jerry Zhao, Daniel Grubb, Harrison Liew, Howard Mao, Albert Ou, Colin Schmidt, Samuel Steffl, John Wright, Ion Stoica, Jonathan Ragan-Kelley, Krste Asanovic, Borivoje Nikolic, and Yakun Sophia Shao. 2021. Gemmini: Enabling 13
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
Systematic Deep-Learning Architecture Evaluation via Full-Stack Integration. In 2021 58th ACM/IEEE Design Automation Conference (DAC). 769–774. doi:10.1109/DAC18074.2021.9586216 [Ghodrati et al.(2024)] Soroush Ghodrati, Sean Kinzer, Hanyang Xu, Rohan Mahapatra, Yoonsung Kim, Byung Hoon Ahn, Dong Kai Wang, Lavanya Karthikeyan, Amir Yazdanbakhsh, Jongse Park, Nam Sung Kim, and Hadi Esmaeilzadeh. 2024. Tandem Processor: Grappling with Emerging Operators in Neural Networks. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (La Jolla, CA, USA) (ASPLOS ’24). Association for Computing Machinery, New York, NY, USA, 1165–1182. doi:10.1145/3620665.3640365 [Gu et al.(2022)] Jiazhen Gu, Xuchuan Luo, Yangfan Zhou, and Xin Wang. 2022. Muffin: testing deep learning libraries via neural architecture fuzzing. In Proceedings of the 44th International Conference on Software Engineering (Pittsburgh, Pennsylvania) (ICSE ’22). Association for Computing Machinery, New York, NY, USA, 1418–1430. doi:10.1145/3510003.3510092 [Guo et al.(2021)] Qianyu Guo, Xiaofei Xie, Yi Li, Xiaoyu Zhang, Yang Liu, Xiaohong Li, and Chao Shen. 2021. Audee: automated testing for deep learning frameworks. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering (Virtual Event, Australia) (ASE ’20). Association for Computing Machinery, New York, NY, USA, 486–498. doi:10.1145/3324884.3416571 [Jin et al.(2020)] Tian Jin, Gheorghe-Teodor Bercea, Tung D Le, Tong Chen, Gong Su, Haruki Imai, Yasushi Negishi, Anh Leu, Kevin O’Brien, Kiyokuni Kawachiya, et al. 2020. Compiling onnx neural network models using mlir. arXiv preprint arXiv:2008.08272 (2020). [Kung et al.(2019)] H.T. Kung, Bradley McDanel, and Sai Qian Zhang. 2019. Packing Sparse Convolutional Neural Networks for Efficient Systolic Array Implementations: Column Combining Under Joint Optimization. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (Providence, RI, USA) (ASPLOS ’19). Association for Computing Machinery, New York, NY, USA, 821–834. doi:10.1145/3297858.3304028 [Liu et al.(2023a)] Jiawei Liu, Jinkun Lin, Fabian Ruffy, Cheng Tan, Jinyang Li, Aurojit Panda, and Lingming Zhang. 2023a. NNSmith: Generating Diverse and Valid Test Cases for Deep Learning Compilers. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (Vancouver, BC, Canada) (ASPLOS 2023). Association for Computing Machinery, New York, NY, USA, 530–543. doi:10.1145/3575693.3575707 [Liu et al.(2023b)] Jiawei Liu, Jinjun Peng, Yuyao Wang, and Lingming Zhang. 2023b. NeuRI: Diversifying DNN Generation via Inductive Rule Inference. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (San Francisco, CA, USA) (ESEC/FSE 2023). Association for Computing Machinery, New York, NY, USA, 657–669. doi:10.1145/3611643.3616337 [Luo et al.(2021)] Weisi Luo, Dong Chai, Xiaoyue Ruan, Jiang Wang, Chunrong Fang, and Zhenyu Chen. 2021. GraphBased Fuzz Testing for Deep Learning Inference Engines. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). 288–299. doi:10.1109/ICSE43902.2021.00037 [Lym and Erez(2020)] Sangkug Lym and Mattan Erez. 2020. FlexSA: Flexible Systolic Array Architecture for Efficient Pruned DNN Model Training. CoRR abs/2004.13027 (2020). arXiv:2004.13027 https://arxiv.org/abs/ 2004.13027 [Ma et al.(2023)] Haoyang Ma, Qingchao Shen, Yongqiang Tian, Junjie Chen, and Shing-Chi Cheung. 2023. Fuzzing Deep Learning Compilers with HirGen. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (Seattle, WA, USA) (ISSTA 2023). Association for Computing Machinery, New York, NY, USA, 248–260. doi:10.1145/3597926.3598053 [Mu et al.(2025)] Yanzhou Mu, Juan Zhai, Chunrong Fang, Xiang Chen, Zhixiang Cao, Peiran Yang, Kexin Zhao, An Guo, and Zhenyu Chen. 2025. Improving Deep Learning Framework Testing with Model-Level Metamorphic Testing. Proc. ACM Softw. Eng. 2, ISSTA, Article ISSTA095 (June 2025), 23 pages. doi:10.1145/3728972 [Parashar et al.(2019)] Angshuman Parashar, Priyanka Raina, Yakun Sophia Shao, Yu-Hsin Chen, Victor A. Ying, Anurag Mukkara, Rangharajan Venkatesan, Brucek Khailany, Stephen W. Keckler, and Joel Emer. 2019. Timeloop: A Systematic Approach to DNN Accelerator Evaluation. In 2019 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). 304–315. doi:10.1109/ISPASS.2019.00042 [Paszke et al.(2019)] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Yang, Zach DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. 2019. PyTorch: an imperative style, high-performance deep learning library. Curran Associates Inc., Red Hook, NY, USA. 14
Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints
[Pham et al.(2019)] Hung Viet Pham, Thibaud Lutellier, Weizhen Qi, and Lin Tan. 2019. CRADLE: Cross-Backend Validation to Detect and Localize Bugs in Deep Learning Libraries. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). 1027–1038. doi:10.1109/ICSE.2019.00107 [Shen et al.(2021)] Qingchao Shen, Haoyang Ma, Junjie Chen, Yongqiang Tian, Shing-Chi Cheung, and Xiang Chen. 2021. A comprehensive study of deep learning compiler bugs. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Athens, Greece) (ESEC/FSE 2021). Association for Computing Machinery, New York, NY, USA, 968–980. doi:10.1145/3468264.3468591 [Shen et al.(2025)] Qingchao Shen, Zan Wang, Haoyang Ma, Yongqiang Tian, Lili Huang, Zibo Xiao, Junjie Chen, and Shing-Chi Cheung. 2025. Optimization-Aware Test Generation for Deep Learning Compilers. arXiv:2511.18918 [cs.SE] https://arxiv.org/abs/2511.18918 [Steinhöfel and Zeller(2022)] Dominic Steinhöfel and Andreas Zeller. 2022. Input invariants. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 583–594. [Steinhöfel and Smytzek(2022)] Dominic Steinhöfel and Marius Smytzek. 2022. rindPHI/islearn: ISLearn 0.2.13. doi:10.5281/zenodo.7035007 [Wang et al.(2024)] Haoyu Wang, Junjie Chen, Chuyue Xie, Shuang Liu, Zan Wang, Qingchao Shen, and Yingquan Zhao. 2024. MLIRSmith: Random Program Generation for Fuzzing MLIR Compiler Infrastructure. In Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (Echternach, Luxembourg) (ASE ’23). IEEE Press, 1555–1566. doi:10.1109/ASE56229.2023.00120 [Wang et al.(2023)] Zihan Wang, Pengbo Nie, Xinyuan Miao, Yuting Chen, Chengcheng Wan, Lei Bu, and Jianjun Zhao. 2023. GenCoG: A DSL-Based Approach to Generating Computation Graphs for TVM Testing. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (Seattle, WA, USA) (ISSTA 2023). Association for Computing Machinery, New York, NY, USA, 904–916. doi:10.1145/ 3597926.3598105 [Wang et al.(2020)] Zan Wang, Ming Yan, Junjie Chen, Shuang Liu, and Dongdi Zhang. 2020. Deep learning library testing via effective model generation. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Virtual Event, USA) (ESEC/FSE 2020). Association for Computing Machinery, New York, NY, USA, 788–799. doi:10.1145/ 3368089.3409761 [Xie et al.(2022)] Danning Xie, Yitong Li, Mijung Kim, Hung Viet Pham, Lin Tan, Xiangyu Zhang, and Michael W. Godfrey. 2022. DocTer: documentation-guided fuzzing for testing deep learning API functions. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (Virtual, South Korea) (ISSTA 2022). Association for Computing Machinery, New York, NY, USA, 176–188. doi:10.1145/3533767.3534220 [Xu et al.(2023)] Rui Xu, Sheng Ma, Yang Guo, and Dongsheng Li. 2023. A Survey of Design and Optimization for Systolic Array-based DNN Accelerators. ACM Comput. Surv. 56, 1, Article 20 (aug 2023), 37 pages. doi:10.1145/3604802 [Yang et al.(2024)] Chenyuan Yang, Yinlin Deng, Runyu Lu, Jiayi Yao, Jiawei Liu, Reyhaneh Jabbarvand, and Lingming Zhang. 2024. WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models. Proc. ACM Program. Lang. 8, OOPSLA2, Article 296 (Oct. 2024), 27 pages. doi:10.1145/3689736 [Yu et al.(2026)] Guangba Yu, Zirui Wang, Yujie Huang, Renyi Zhong, Yuedong Zhong, Yilun Wang, and Michael R. Lyu. 2026. Why Does the LLM Stop Computing: An Empirical Study of User-Reported Failures in Open-Source LLMs. arXiv:2601.13655 [cs.SE] https://arxiv.org/abs/2601.13655 [Zamudio Amaya et al.(2025)] José Antonio Zamudio Amaya, Marius Smytzek, and Andreas Zeller. 2025. FANDANGO: Evolving Language-Based Testing. Proc. ACM Softw. Eng. 2, ISSTA, Article ISSTA040 (June 2025), 23 pages. doi:10.1145/3728915 [Zhou et al.(2024)] Chijin Zhou, Bingzhou Qian, Gwihwan Go, Quan Zhang, Shanshan Li, and Yu Jiang. 2024. PolyJuice: Detecting Mis-compilation Bugs in Tensor Compilers with Equality Saturation Based Rewriting. Proc. ACM Program. Lang. 8, OOPSLA2, Article 317 (Oct. 2024), 27 pages. doi:10.1145/3689757
15