BitIR: Cross-Architecture Fault Injection for Resilience Analysis of Heterogeneous GPU Applications

BitIR: Cross-Architecture Fault Injection for Resilience Analysis of Heterogeneous GPU Applications Maisy Dunlavy∗ , Michael E. Papka †∗ , Zhiling Lan∗† ∗ University of Illinois Chicago, USA

† Argonne National Laboratory, USA

arXiv:2610.04037v1 [cs.DC] 2 Oct 2026

{mdunl6, papka, zlan}@uic.edu Abstract—Modern GPU-based HPC systems rely on heterogeneous vendor stacks, yet resilience studies are largely limited to single architectures, leaving it unclear how faults behave across different GPU backends. We present BitIR, a cross-architecture fault injection framework that injects deterministic single-bit faults at the LLVM IR level, ensuring semantically equivalent perturbations prior to backend lowering and enabling direct cross-vendor comparison across NVIDIA, Intel, and AMD GPUs. We evaluate BitIR on three production supercomputers – Polaris (ALCF, NVIDIA A100), Aurora (ALCF, Intel GPU Max 1550), and Frontier (OLCF, AMD Instinct MI250X) – representing the full spectrum of current leadership-class GPU architectures. Using representative heterogeneous benchmarks, we conduct large-scale injection campaigns across all three systems and classify outcomes into masked results, silent data corruptions (SDCs), and failures. Our results show that identical faults produce markedly different behaviors across vendors: Intel most often masks faults but exhibits more hangs when faults escape masking, NVIDIA exposes more detectable hard failures, and AMD alternates between SDC-dominant and failure-dominant behavior depending on the benchmark and fault site. These findings demonstrate that resilience is not backend-invariant, underscoring the need for backend-aware and workload-aware fault mitigation. Index Terms—Fault Injection, GPU resilience, Heterogeneous Application, LLVM IR

I. I NTRODUCTION Graphics Processing Units (GPUs) are now central to modern high-performance computing (HPC) and AI systems. As these platforms continue to scale, they become increasingly vulnerable to transient faults caused by radiation, voltage noise, and timing variation [1], [2]. Although hardware protection mechanisms mitigate some of these effects, many faults still propagate to software-visible state and can ultimately alter application behavior. In heterogeneous applications, where GPUs execute the dominant computational kernels, even a single bit perturbation can lead to silent corruption, abnormal termination, or stalled execution [3], [4]. Understanding how GPU applications behave under transient faults is, therefore, an important resilience problem. This is especially true for scientific and data-intensive workloads, where incorrect outputs may be difficult to detect and where GPU kernels can fail silently without OS-level signals or reliable log evidence. A useful resilience study must therefore characterize faults at the application level, based on software-

To Appear at SC26, November 15-20, 2026, Chicago, Illinois, USA

visible outcomes rather than only low-level hardware events [5], [6]. A key open question is whether the same logical fault (i.e., a semantically equivalent perturbation applied at the same program point) produces the same outcome across different GPU backends. None of the existing literature has been able to address this directly because they are typically confined to a single vendor stack or a single abstraction level. Hardware and microarchitecture level approaches provide detailed insight into many complex GPU resilience issues [3], [7], but they are tightly coupled to particular architectures and do not support direct cross-platform comparison. Software-based approaches improve portability and allow for the potential of cross-platform comparison [8], [9], [10], but many operate on backend-specific representations such as assembly or vendor binaries, making it difficult to define an equivalent fault across different GPU ecosystems. This gap motivates a cross-architecture fault-injection methodology grounded in a common, software-visible abstraction. We introduce BitIR (Bit-flip Intermediate Representation), a unified framework for resilience analysis across heterogeneous GPU platforms that injects deterministic single-bit faults at the LLVM intermediate representation (IR) level before backend-specific lowering. By operating on the shared IR rather than on vendor-compiled binaries, BitIR defines faults in terms of program semantics rather than backend-specific encodings, which allows the perturbation to be truly equivalent across NVIDIA (CUDA), Intel (SYCL), and AMD (HIP) compilation flows. BitIR targets three classes of softwarevisible values: instruction results, operands, and pointer-related values. It also supports deterministic site enumeration, aligned worklist construction, backend-specific lowering, and outputbased fault classification against golden references, all of which enables large-scale campaigns on real production systems while preserving a shared fault model across vendors. Unlike many prior GPU fault-injection studies that rely on statistical or randomized sampling of fault locations for tractability [8], [9], [10], [11], BitIR exhaustively evaluates the complete aligned injection space for each benchmark. This is particularly important for cross-vendor comparison, where sparse sampling can miss backend-specific divergence concentrated in specific workloads, instruction classes, or site categories.

Fig. 1: Overview of the BitIR pipeline.

Using BitIR, we conduct large-scale injection campaigns on representative heterogeneous benchmarks across three production supercomputers: Polaris (ALCF, NVIDIA A100), Aurora (ALCF, Intel Data Center GPU Max 1550), and Frontier (OLCF, AMD Instinct MI250X). Our results show that resilience is not backend-invariant and that the same aligned fault often produces drastically different outcomes for each vendor. These differences are especially pronounced for memory-access and pointer-bearing sites and vary substantially by workload, underscoring the need for backend-aware and workload-aware fault mitigation. Specifically, this work makes the following contributions: • We introduce BitIR, the first LLVM IR-based framework for cross-architecture fault injection across NVIDIA, Intel, and AMD GPUs, featuring deterministic site enumeration, aligned worklist construction, and reproducible campaign execution on production supercomputers (§III). • We conduct an extensive empirical study using BitIR across three leadership-class supercomputers (Polaris, Aurora, and Frontier) on representative heterogeneous benchmarks, comparing execution outcomes under a shared IR-level fault model (§IV). • We show that resilience differences across GPU backends are strongly shaped by workload structure and injected IR site characteristics, with concrete implications for backend-aware and workload-aware fault mitigation (§V). • We discuss guidelines and recommendations for fault mitigation strategies tailored to the hardware platform on which an application is deployed (§VI). II. K EY C HALLENGES We now identify the practical challenges that arise when studying transient faults at the application level1 in heterogeneous GPU systems. These challenges stem not only from the nature of fault propagation but also from the difficulty of defining consistent fault models and conducting reproducible experiments across diverse backend software stacks. 1 We use “application-level” and “software-visible” interchangeably to denote behavior observable at the program level (e.g., outputs, execution status, or runtime errors), as opposed to microarchitectural or hardware level effects.

Challenge 1. In GPU applications, fault outcomes are often difficult to classify. A program may complete while producing incorrect outputs, or it may report runtime or benchmarklevel errors while still producing outputs matching the golden reference. Consequently, exit status and runtime-level signals alone are insufficient for distinguishing masked outcomes, silent data corruption, failures, and hangs [5], [6]. Reliable classification, therefore, requires application-aware comparison against expected outputs. Challenge 2. Cross-platform comparison is difficult because NVIDIA CUDA, Intel SYCL, and AMD HIP rely on distinct compiler toolchains and backend representations [12], [13], [14]. 2 If faults are injected after backend lowering, the injected perturbation is tied to backend-specific instructions, and the resulting campaigns cannot be compared under a common fault model. This limits the ability to draw meaningful crossarchitecture conclusions. Challenge 3. Large-scale GPU fault injection is also an execution-management problem. Each injection may require recompilation, device code generation, benchmark execution, output collection, and result classification. Scaling to thousands of fault sites and bit positions, therefore, requires deterministic work partitioning, scheduler-aware execution, restartable campaigns, and reliable aggregation from persistent artifacts. Without these capabilities, large campaigns become difficult to reproduce and validate. BitIR addresses each challenge directly. Outcomes are classified against golden references rather than exit status alone (Challenge 1); fault injection is performed before backend lowering, enabling semantically aligned perturbations across CUDA, SYCL, and HIP (Challenge 2); and experiments are organized as deterministic, worklist-driven campaigns with persistent per-run artifacts, enabling scalable and reproducible execution (Challenge 3).

2 SYCL and HIP are portable programming models and are not restricted to Intel and AMD hardware, respectively. In this work, we associate SYCL with Intel and HIP with AMD because these are the primary vendor-supported programming environments used on the evaluated platforms and serve as the closest practical counterparts to CUDA on NVIDIA.

III. M ETHODOLOGY Given a heterogeneous application that offloads computeintensive kernels to GPUs, our goal is to systematically characterize how single-bit faults affect application resilience across NVIDIA, Intel, and AMD GPU architectures under a common fault model. To enable fair and consistent crossplatform comparison, our methodology enforces deterministic execution, output-equivalent validation, and precise alignment of injected sites across vendor backends. Figure 1 illustrates the overall workflow. At the core of BitIR is the LLVM intermediate representation (IR)[15], which serves as a unifying software-visible abstraction prior to backend lowering. LLVM IR is typed, static single assignment (SSA)-based, and widely used in modern CPU and GPU compilation pipelines before vendorspecific code generation. Unlike backend binaries, LLVM IR preserves instruction structure, operand relationships, and type information, allowing faults to be defined in terms of program semantics rather than hardware-specific encodings. Using LLVM IR and its debug metadata, BitIR constructs deterministic site/bit worklists, applies aligned injections across platforms, and classifies outcomes through comparison against golden outputs. Cross-architecture equivalence is essential to the validity of our study. We define it as follows: equivalence holds if, for all platforms, each fault injection satisfies (i) input equivalence — identical program inputs and output comparison criteria; (ii) fault equivalence — the same bit position is perturbed in a semantically equivalent LLVM IR object across all backends; and (iii) interpretation equivalence — results are classified and aggregated under a common methodology. A. Golden Reference Generation For each application, we first establish a golden reference output by executing the fault-free benchmark with hooks that emits a deterministic binary snapshot of its final program state. This includes output buffers, result arrays, or other application-specific outputs for each benchmark. We verify that all expected outputs are generated and non-empty, then repeat the execution and compare the resulting snapshots for bitwise equivalence. Additional fault-free baseline executions were performed during campaign validation and consistently reproduced the corresponding golden references. This verification procedure ensures that we are able to produce stable, deterministic outputs for each benchmark that can be used for output classification throughout injection campaigns. B. LLVM IR-Level Fault Injection Fault injection is performed at the LLVM IR level under a unified fault model through three steps: site enumeration, worklist construction, and injection execution. Site Enumeration. We traverse the device-side LLVM IR of each application to identify eligible injection sites. A site is defined as any LLVM IR-visible target for which a fault can be introduced. Each site is assigned a deterministic

site_id based on a fixed traversal order, ensuring stability and reproducibility across runs on unchanged IR. Each site is annotated with several attributes. The site class captures the role of the site in the IR. Result sites model corruption of a computed value, operand sites perturb an instruction input, and pointer sites corrupt a device memory address, typically via a getelementptr chain. The value type determines the bit width and semantic interpretation of the perturbation. Integer sites cover indices, counters, control-flow conditions, and arithmetic results, floating-point sites appear in arithmetic kernels, where exponent flips shift values by orders of magnitude and mantissa flips introduce bounded relative error, and pointer sites hold memory addresses whose corruption may redirect loads or stores to invalid regions, producing outcomes from silent overwrite to access violation. Additional attributes, such as opcode and function context are recorded to support cross-platform site alignment. Worklist Construction. For each enumerated site, BitIR constructs a worklist of (site_id, bit_index) pairs, where the bit index ranges over all bit positions of the target value for each site (e.g., 32 positions for float and typically 64 for pointers on modern GPU backends). Each sitebit pair uniquely identifies a single fault injection experiment. These pairs serve as primary keys in both the worklist and the resulting per-run output artifacts. We validate the reproducibility and stability of this methodology by regenerating site inventories and confirming identical IDs, bit widths, and metadata across runs on unchanged IR. Injection Execution. Given a (site_id, bit_index) pair, the injector locates the target IR object, bitcasts it to an integer of matching width, applies an XOR with a onehot mask at the specified bit position, and bitcasts the result back to its original type, guaranteeing a single-bit flip that preserves type correctness. This mechanism allows faults to be introduced uniformly across different LLVM IR-visible targets while keeping the perturbation semantics reproducible. BitIR records a shared metadata schema for each candidate site, including target class, opcode, type, bit width, operand index, function context, source location, and a signature ordinal that disambiguates sites sharing the same source location. These attributes are combined into what we refer to as a semantic identifier that characterizes the LLVM IR object independently of any vendor-specific profiling or numbering schemas. To maintain cross-platform alignment, sites with semantic identifiers that do not map cleanly across vendor compilation flows are pruned. Only 15 of 1150 total injection sites (1.3%) were removed from the aligned benchmark set. These sites correspond to backend or compiler-specific helper machinery, including CUDA builtin-variable helpers, shuffle intrinsics, and device-function wrappers introduced by Clang CUDA support headers. These sites represent a negligible fraction of candidate sites and preserves near-complete coverage of the aligned injection space. No injection runs were executed for pruned injection sites.

C. Backend Lowering After IR-level injection, the modified IR is lowered through each vendor’s native compilation pipeline into a runnable benchmark. The injected fault remains semantically invariant across platforms with the same aligned IR site/bit perturbed before lowering, but we do not assume identical backend compilation or runtime behavior. Instead, any differences that emerge during lowering and execution (e.g., instruction selection, register allocation, memory access lowering, and runtime handling) are treated as part of the backend behavior that BitIR is designed to expose. • NVIDIA CUDA 11.8.0: The injected IR is lowered to PTX and packaged into a fat binary via the CUDA toolchain. • Intel oneAPI DPC++/C++ Compiler 2025.2.0 : The injected IR is lowered to SPIR-V and reintegrated into the host executable, where it is JIT-compiled to native Gen/Xe device code at runtime. • AMD ROCm 6.4.2: The injected IR is lowered through the AMDGPU backend via the HIP/ROCm toolchain and linked into the final device binary. To reduce compilation overhead, unmodified device IR is cached when the corresponding source is unchanged; controlled A/B tests confirm that caching does not affect experimental outcomes. As a sanity check, we confirmed that injected IR modules successfully propagate through each backend compilation flow and produce observable non-masked outcomes after execution. Figure 2 shows a representative example. For conciseness, only the NVIDIA lowering path is shown, although equivalent validation was performed for the Intel and AMD backends. Across all three platforms, the same IR-level injection mechanism produces SDCs, hard failures, and hangs, demonstrating that the injected perturbations are not systematically eliminated during lowering. Individual M ASKED outcomes may still arise from backend optimization or later masking, and we do not attempt to distinguish these mechanisms for every injection in this study. D. Output Classification Each fault injection produces per-run artifacts (siteX_bitY.out and siteX_bitY.err) corresponding to a single pair of (site_id, bit_index). The generated output is compared against platform-specific golden references using benchmark-specific comparators and classified as follows (Figure 3): (i) if the output matches within tolerance, the result is M ASKED; (ii) if the output differs but the application completes normally and produces a non-empty, well-formed result, it is SDC; and (iii) if execution terminates abnormally due to a crash, runtime error, or compiler error, it is FAILURE; executions exceeding a per-run timeout are forcibly terminated and recorded as H ANG, a tracked subtype of FAILURE. If an output file is missing, the site/bit pair is re-run rather than assumed to be a FAILURE outcome. Only upon

CUDA Source float v = a[i] + b[i]; out[i] = v; ↓ LLVM IR Before Injection %v = fadd float %a.val, %b.val store float %v, ptr %out.ptr ↓ BitIR: flip bit 13 LLVM IR After Injection %v = fadd float %a.val, %b.val %bits = bitcast float %v to i32 %flip = xor i32 %bits, 8192 %v.fi = bitcast i32 %flip to float store float %v.fi, ptr %out.ptr ↓ backend lowering Lowered Representation add.f32 %f3, %f1, %f2 mov.b32 %r1, %f3 xor.b32 %r1, %r1, 0x00002000 st.global.u32 [%rd_out], %r1

Fig. 2: Example of BitIR’s aligned LLVM IR-level fault injection. A fault is specified as a (site ID, bit index) pair before vendor-specific lowering. Although lowering differs across backends, the same pair identifies the same logical perturbation, which survives when the lowered computation depends on the corrupted value.

completing twice with no output is it considered to be a FAILURE. BitIR supports multiple output forms, including floatingpoint arrays, exact binary dumps, and benchmark-specific textual outputs. For floating-point outputs, we perform elementwise comparison using a fixed absolute tolerance of 10−5 and classify a run as M ASKED only if all elements satisfy this threshold; otherwise, it is classified as SDC. For our selected floating-point benchmarks, a fixed absolute tolerance was sufficient because fault-free baseline runs compared cleanly against their golden outputs at this threshold, while avoiding the instability of relative error for output values near zero. This threshold was appropriate for our benchmark set, but other benchmarks may require benchmark-specific relative tolerances. For binary outputs, exact bytewise equality is required to be considered M ASKED. We implement timeout thresholds to prevent stalled executions from blocking large-scale campaigns while preserving visibility into hang-induced fault behavior. Timeout thresholds are set to 200 seconds for all benchmarks, which is sub-

Most kernels in the suite also include integrated correctness checks and produce deterministic outputs, making them directly comparable against a golden reference and simplifying outcome classification. Benchmark parameters are chosen to balance execution size, per-injection runtime, and output stability across repeated fault-free runs. The injection scale varies across our chosen benchmarks, since each benchmark exposes a different number of eligible LLVM IR injection sites with potentially different bit widths. Table II summarizes the selected benchmarks, workload categories, runtime parameters, and injection scale. D. Run-to-Run Stability

Fig. 3: Outcome taxonomy. stantially higher than the observed fault-free execution times (mean execution time is below 35 seconds for all benchmarks). This ensures that hang classification reflects abnormal execution behavior rather than backend-specific performance differences. Aggregate outcome statistics are constructed directly from per-run *.out artifacts, ensuring reproducibility, campaign restartability, and cross-architecture equivalence. IV. I MPLEMENTATION AND E VALUATION A. BitIR Implementation BitIR is a multi-component LLVM-based GPU fault injection framework built on LLVM 17.0.0 [15] and integrated with CUDA, SYCL, and HIP toolchains. It consists of three components: (1) an LLVM pass plugin (libfi_inject.so) for IR-level fault injection, implemented in C++; (2) backend compilation flows, orchestrated via Bash, that lower injected IR through vendor-specific toolchains into executable binaries; and (3) a Python-based campaign execution layer that manages site inventory generation, worklist construction, cross-platform alignment, result aggregation, and integration with the schedulers. B. Hardware Platforms Experiments were conducted on three production supercomputers: Polaris (ALCF) with NVIDIA A100 GPUs, Aurora (ALCF) with Intel Data Center GPU Max 1550 GPUs, and Frontier (OLCF) with AMD Instinct MI250X GPUs. Table I summarizes the hardware configuration for each system. C. Benchmarks Our experiments use the HeCBench benchmark suite [16], which spans a broad range of computational motifs representative of modern HPC GPGPU workloads, including numerical kernels, search, image processing, and encoding/decoding tasks. HeCBench provides native implementations in CUDA, SYCL/DPC++, and HIP for all benchmarks in the suite, making it a prime candidate for any cross architecture study.

To assess run-to-run stability, we performed repeated executions for a sampled subset of injection points, consisting of 300 site/bit pairs per benchmark spread across each GPU platform evenly. The vast majority of injection outcomes are deterministic across runs. Only 1.42% of the sampled injections exhibited outcome variability across runs, with pointer-related sites accounting for 76.5% of unstable cases. This is consistent with the semantics of pointer and address manipulation in low-level parallel programming models, where corrupted addresses may result in implementation-dependent execution behavior [12], [13], [14]. Given the low rate and structured nature of this run-to-run variability, we conclude that these effects do not materially impact the aggregate trends reported in this work. V. R ESILIENCE A NALYSIS We structure our analysis around five research questions targeting distinct dimensions of cross-architecture fault behavior. A. Backend Variance Question 1. Do semantically aligned IR-level faults produce consistent outcome distributions across NVIDIA, Intel, and AMD GPU backends, or does resilience vary significantly by platform? Table III summarizes coarse outcome ratios across the aligned three-backend benchmark set, and Figure 4 shows the corresponding fine-grained breakdown. Together, these views confirm that resilience varies substantially by backend. Outcome distributions differ consistently and substantially by backend across all benchmarks, with clear shifts in the balance between M ASKED, SDC, and FAILURE outcomes. The largest separations appear in dense-embedding, layout, colorwheel, and jacobi, where backend choice strongly influences the dominant outcome class. Even in cases where coarse outcome ratios appear similar, the manifestation of nonmasked faults differs across platforms. Cross-backend agreement is limited: only 10.4% of aligned injections produce the same outcome across all three platforms, while most cases exhibit partial or complete disagreement. Interestingly, pairwise transitions show consistent divergence. For example, outcomes that are M ASKED on Intel or NVIDIA frequently become SDC on AMD (over 83% of

System

Scheduler

Polaris (ALCF) Aurora (ALCF)

Peak PFlop/s per Node 0.0388 0.130

Frontier (OLCF)

0.1912

Slurm

PBS PBS

CPU Configuration per Node

GPU Configuration per Node

1×AMD EPYC 7543P, 512 GiB DDR4 2×Intel Xeon Max 9470C, 2×512 GiB DDR5 1×64-core AMD EPYC 7A53, 512 GiB DDR4

4×NVIDIA A100, 40 GiB HBM2 6×Intel Max 1550, 768 GiB HBM2e 4×AMD MI250X, 64 GiB HBM2e

TABLE I: Hardware configuration of the three production supercomputers used in this study. Benchmark matrix-rotate jacobi layout dense-embedding pathfinder entropy colorwheel randomAccess

Category Math (Index Re-Mapping) Math (Iterative Propagation) Classification Machine Learning Simulation Encoding/Decoding Image Processing Bandwidth (Memory Access)

Args [10000, 1] None [1] [10000, 8, 1] [10000, 1000, 5] [10000, 1024, 1] [10000, 8, 1] [1]

#Sites 84 195 38 132 154 184 243 120

#Bits 10,532 20,962 5,764 19,564 17,831 21,306 27,162 17,892

Result 27.4% 31.7% 23.4% 23.4% 26.0% 25.2% 27.3% 32.5%

Operand 27.7% 32.3% 23.4% 23.9% 24.9% 25.8% 31.2% 32.1%

Pointer 44.9% 36.0% 53.2% 52.7% 49.1% 49.0% 41.5% 35.4%

TABLE II: Selected HeCBench benchmarks, execution arguments, and resulting injection scale. Args reports the exact commandline values used for each benchmark (argument names, ordering, and benchmark-specific semantics are documented in the corresponding benchmark directory in the HeCBench documentation [16]). Sites reports the number of eligible LLVM IRvisible injection sites, Bits reports the total number of single-bit injections in the benchmark worklist. The final three columns show the distribution of those injections across result, operand, and pointer site classes. Benchmark jacobi

Backend NVIDIA Intel AMD pathfinder NVIDIA Intel AMD entropy NVIDIA Intel AMD randomAccess NVIDIA Intel AMD

Masked 45.1% 84.6% 1.3% 49.1% 85.2% 2.1% 53.2% 79.2% 5.9% 45.8% 79.0% 9.0%

SDC 50.1% 7.6% 95.1% 50.9% 7.1% 84.4% 23.7% 7.8% 1.1% 33.4% 14.1% 86.8%

Failure 4.8% 7.8% 3.6% 0.0% 7.7% 13.4% 23.1% 13.0% 93.1% 20.7% 6.8% 4.2%

Benchmark matrixrotate denseembedding layout

colorwheel

Backend NVIDIA Intel AMD NVIDIA Intel AMD NVIDIA Intel AMD NVIDIA Intel AMD

Masked 24.4% 0.0% 0.9% 54.1% 66.7% 0.7% 85.5% 97.6% 4.5% 0.0% 68.8% 17.1%

SDC 38.7% 92.8% 94.4% 45.5% 32.4% 17.8% 14.4% 1.3% 84.6% 87.3% 24.3% 0.3%

Failure 36.9% 7.2% 4.7% 0.4% 0.9% 81.5% 0.1% 1.1% 10.9% 12.7% 6.9% 82.6%

TABLE III: Outcome ratios across the aligned three-backend benchmark set. Percentages are rounded.

cases), while SDC on NVIDIA is masked by Intel in more than half of cases. AMD also shifts outcomes toward higher severity more often than either NVIDIA or Intel. Finding 1. Semantically aligned IR-level faults do not yield backend-stable resilience behavior. The same perturbation may be masked on one backend, silently corrupt output on another, and surface as a hard failure on a third, so resilience conclusions drawn from a vendor do not transfer to others. B. Site Class and Value Type Analysis Question 2. How does fault outcome vary across injection site classes and value type (§III-B), and does this sensitivity differ across GPU backends? Figure 5 shows the breakdown by site class and value type, while Figure 6 shows which instruction-level structures sharpen these backend differences. Together, these views confirm that outcome sensitivity is strongly shaped by site class and value type, but not in the same way across all backends.

Injection class. The data show that site class matters, but differently on each backend. Across result and operand sites, Intel remains predominantly M ASKED, NVIDIA is SDCheavy, and AMD is largely non-masked. Pointer sites are the strongest separator:NVIDIA shows a mix of SDC and FAILURE, Intel remains mostly M ASKED but with its highest FAILURE and H ANG rates among all site classes, and AMD produces minimal masking with the highest non-masked fraction across all three classes. Value type. Value type shows a consistent pattern across backends, with floating-point sites have the highest masking rates overall, while integer and pointer sites concentrate FAILURE and SDC N O F LAG outcomes, as perturbations in control-flow, indexing, and address computation propagate more directly to observable failures than small numerical perturbations in iterative arithmetic. Opcode-level structure. At the opcode level, divergence is concentrated in memory and address-generation instruction families (Figure 6). Integer and control-bearing opcodes such as xor, select, shl, and udiv show particularly strong

Fig. 4: Fine-grained outcome distributions across benchmarks and backends, using the full six-class outcome taxonomy.

all classes, NVIDIA concentrates non-masked faults as SDC, and AMD shifts aggressively toward hard failure, particularly at pointer and integer sites. C. Workload Analysis Question 3. To what extent does workload structure determine resilience behavior, and are certain computational motifs systematically more vulnerable than others across all three platforms?

Fig. 5: Fine-grained outcome distributions broken down by injection class (top) and value type (bottom).

cross-backend separation. They are nearly entirely M ASKED on Intel but produce predominantly SDC on NVIDIA and FAILURE on AMD, confirming that divergence is not limited to memory operations. Finding 2. Fault outcome is strongly structured by injection class and value type, but the sensitivity is backend-dependent. Pointer-bearing and integer/control-bearing sites drive the strongest cross-backend divergence. Intel masks heavily across

Table III provides the benchmark-level coarse outcome ratios, and Figure 7 highlights representative benchmark-opcode combinations where the dominant outcome class differs across vendors. Together, they show that workload structure exposes different backend-specific regimes rather than preserving a single global resilience ordering. Workload structure exposes different backend-specific regimes rather than preserving a single global resilience ordering. Iterative kernels such as jacobi and pathfinder show a consistent split: Intel is predominantly masked, NVIDIA is split between masked and SDC, and AMD is strongly SDC-heavy. Memory-bound and transformationheavy kernels exhibit different patterns, with some workloads showing SDC-dominant behavior across Intel and AMD while others drive AMD toward failure-heavy regimes. In several cases, the dominant outcome class differs entirely across vendors for the same benchmark–opcode combination, confirming that fault manifestation depends jointly on workload context and backend execution behavior. These patterns are consistent with documented backend execution behavior. Intel’s SYCL execution model exposes sub-group and work-group level execution and synchronization semantics that can influence how perturbations propagate through collective and iterative kernels [13]. NVIDIA’s CUDA programming model specifies that illegal or out-of-bounds memory accesses may result in runtime errors or program termination, which is consistent with the larger fraction of

Fig. 6: Fine-grained outcome distributions by the six most frequently injected LLVM IR instructions.

Fig. 7: Representative backend divergence points: benchmark-opcode pairs where the dominant coarse outcome class differs across NVIDIA, Intel, and AMD. Cell color indicates the dominant outcome: green (M ASKED), gray (SDC), and red (FAILURE). Percentages reflect the fraction of injections producing the dominant outcome for that backend.

overt failures observed in address-sensitive paths [12]. Similarly, AMD’s HIP programming model permits execution to continue when memory accesses remain within valid regions, while invalid accesses may produce incorrect results or runtime faults, consistent with the observed mixture of SDCheavy and failure-heavy regimes [14]. Finding 3. Workload structure does not produce a single backend resilience ranking. Different computational motifs expose different vendor-specific propagation regimes, so resilience is workload-aware as well as backend-aware. The same instruction class can be fully M ASKED on one backend, produce silent corruption on another, and trigger hard failure on a third depending on the workload in which it appears. D. SDC and Hang Analysis Question 4. Where is silent data corruption risk concentrated across backends, workloads, and injection sites, and what distinguishes Intel hang behavior from the hard-failure modes observed on NVIDIA and AMD? To ground the cross-architecture patterns identified in Questions 1–3, we examine two forms of non-masked backend divergence that appear repeatedly across the study: silent data corruption risk and hang behavior.

Silent Corruption Risk. Silent data corruption is the most operationally dangerous outcome because the application completes while producing incorrect output. Our data show that SDC risk is not uniformly distributed across backends; it is concentrated in specific combinations of backend, workload, and site structure. Representative examples include AMD pointer and operand sites in jacobi and matrix-rotate, Intel pointer sites in matrix-rotate, and NVIDIA operand and result sites in dense-embedding, all of which are strongly SDC-heavy. At the aggregate level, SDC N O F LAG accounts for 16.3% of aligned injections on NVIDIA, 14.5% on Intel, and 12.5% on AMD. Structurally, SDC risk is concentrated at pointerbearing and operand sites, especially in workloads dominated by index remapping, iterative propagation, or dense arithmetic reuse. Memory- and address-related opcodes such as load, store, and getelementptr are major contributors, because corrupted addresses can still refer to legal but incorrect locations. Integer and control-bearing instructions such as xor, select, shl, and udiv also contribute strongly on NVIDIA and AMD while remaining much more often masked on Intel. These trends show that SDC risk is highly structured rather than uniform across backends, and that the same backend can be SDC-heavy on one workload and failureheavy on another.

Hang Behavior. Hangs are operationally severe because they stall progress and require a timeout or external intervention. In this study, hang behavior is overwhelmingly concentrated on Intel. Across the aligned benchmark set, Intel produces 7.1% H ANG, compared with 0.5% on NVIDIA and 0.2% on AMD. Hang behavior on Intel is workload and site class sensitive. It is the highest in entropy (13.0%), followed by jacobi (7.8%), pathfinder (7.7%), matrix-rotate (7.2%), colorwheel (6.9%), and randomAccess (6.8%). By site class, pointer injections show the highest hang share on Intel; address- and pointer-related combinations are especially hangprone, particularly addrspacecast, getelementptr, and load at pointer sites. Finding 4. SDC risk is concentrated in structured backend– workload–site combinations where perturbed values remain legally executable while producing incorrect output. Hang risk is an Intel-dominated mode driven by pointer-bearing and address-related sites, where non-masked faults retain forward progress long enough to stall rather than terminate. Practical mitigation must therefore be backend-aware. Output validation for SDC, timeout-aware stall recovery for Intel hangs, and fast failure detection for NVIDIA and AMD hard failures. E. Case Study: matrix-rotate Question 5. What does matrix-rotate reveal about the backend-specific mechanisms that determine whether an aligned IR-level fault produces a completed execution with corrupted output or a hard failure, and why does a completed execution alone not imply correctness for this workload? Figure 8 presents a detailed breakdown of matrix-rotate across the fine-grained taxonomy, site-class distributions, and top divergent opcodes. We focus on this benchmark because it exemplifies the most operationally subtle form of backend divergence: completed corruption on Intel and AMD versus hard failure on NVIDIA. At the coarse level, Intel and AMD are almost entirely SDC-heavy (92.8% and 94.4% respectively) while NVIDIA shows a substantially larger failure component at 36.9%. This benchmark is dominated by index remapping and in-place data movement, so many perturbed values lead to legal execution and in-bounds memory access even when the final output is incorrect. Completion is therefore not evidence of resilience. The pointer-site view sharpens this picture most clearly. Pointer injections in matrix-rotate produce 79.1% FAIL URE on NVIDIA, but 94.0% SDC on Intel and 94.8% SDC on AMD, one of the strongest benchmark-specific examples of backend-dependent manifestation in the study. The same aligned class of faults pushes NVIDIA toward overt failure while leaving Intel and AMD in a completed-yet-incorrect regime, consistent with the kernel’s dominant operations being address and index transformations whose perturbed values frequently remain in-bounds while redirecting data to the wrong location. The opcode-level view in Figure 8 confirms that this pattern holds across load, sub, mul, and call

instructions, none of which escape the same NVIDIA-failure versus Intel/AMD-SDC split. Finding 5. In matrix-rotate, the same aligned pointersite fault produces 79.1% FAILURE on NVIDIA but over 94% SDC on Intel and AMD, driven by the kernel’s index and address transformations that frequently yield perturbed values remaining legally in-bounds. For this class of workload, output validation against a golden reference is the most reliable safeguard. VI. I MPLICATIONS FOR GPU R ESILIENCE P RACTICE The observed backend-specific fault behaviors have direct implications for how resilience mechanisms should be deployed in practice. Rather than applying uniform strategies across platforms, mitigation should reflect the dominant failure modes observed for each backend. NVIDIA. Faults more frequently surface as explicit runtime failures, particularly in address-sensitive execution paths and workloads with irregular memory access or index remapping. This behavior favors mitigation centered on rapid detection and controlled recovery, including early termination, checkpoint/restart, and failure-aware execution models [17]. Because these faults are more likely to terminate execution overtly, recovery mechanisms are especially relevant when targeting NVIDIA backends. AMD. Faults are substantially more likely to produce corrupted outputs than explicit failures, making silent data corruption a primary concern. Mitigation on AMD platforms should therefore emphasize application-level output validation and error detection. Algorithm-based fault tolerance (ABFT) [18], [19] and redundant computation are particularly relevant because they can detect silent errors without relying on runtime failure signals. This is especially important for iterative and transformation-heavy workloads, where perturbed values frequently remain in-bounds and propagate to incorrect outputs without triggering hard failures. Intel. Hang behavior is substantially more common on Intel, accounting for 7.1% of injections compared with 0.5% on NVIDIA and 0.2% on AMD. Faults that escape masking can retain forward progress long enough to stall rather than terminate cleanly, making timeout enforcement, hang detection, stall recovery, and failure-aware scheduling important mitigation concerns. Systems targeting Intel backends should therefore pair these mechanisms with checkpoint/restart where recovery from stalled execution is required [17]. These mitigation mechanisms introduce different costs and must be configured according to workload characteristics. Checkpoint/restart introduces storage and synchronization overhead, with appropriate checkpoint granularity depending on application state size, checkpoint cost, and expected failure frequency. ABFT, output validation, and redundant computation introduce additional arithmetic, validation, or duplicated execution cost. Our results do not quantify these overheads or prescribe fixed checkpoint intervals; instead, they identify the backend–workload combinations in which particular forms of protection are most warranted.

Fig. 8: matrix-rotate microstudy: fine-grained outcome distributions by overall benchmark total, site class (value, operand, pointer), and top opcodes (load, sub, mul, call) across NVIDIA, Intel, and AMD.

Practical Impact. During large-scale campaign execution on Aurora, segmentation faults caused nodes to go offline and trigger system maintenance, prompting direct contact from the ALCF operations team. Investigation revealed that these hangs exposed a previously undetected issue in Intel’s GPU system stack. The ALCF operations team subsequently debugged the issue and deployed a fix on Aurora. All Intel results reported in this paper were collected after this fix was applied, so the defect does not affect the reported outcome distributions. This incident demonstrates that cross-architecture fault injection at the IR level can expose system-level vulnerabilities in production GPU environments and, in this case, contributed to identifying and correcting an issue in the deployed system stack. VII. R ELATED W ORK Prior work on GPU resilience spans architectural, microarchitectural, software, and compiler-level perspectives. Foundational architectural studies establish the fault-outcome concepts and evaluation principles underlying resilience analysis [1], [5]. On GPUs, early vulnerability studies show that fault manifestation depends strongly on both microarchitectural location and application behavior. Tan et al. [3] analyze soft-error vulnerability in GPGPU microarchitecture, while Vallero et al. [7] compare reliability behavior across NVIDIA and AMD GPUs. More broadly, prior evidence comes from both modeled or simulation-based analyses and field studies of deployed systems. Radiation-induced and large-scale system studies [2], [4], [20], [21] reinforce the same conclusion that GPU fault outcomes vary substantially with hardware structure, workload, and deployment environment. Together, these studies establish why GPU resilience must be studied empirically, but they do not provide a portable mechanism for injecting semantically aligned faults and observing their manifestation through real application runs across vendor ecosystems. The methods most directly related to BitIR begins with software-visible GPU fault injection. GPU-Qin [8] is among the earliest frameworks for systematic GPU resilience evaluation through software-level fault injection. Later post-backend

frameworks improve realism by injecting faults into vendorspecific instruction streams after compilation. SASSIFI [9] operates at the NVIDIA SASS level, NVBitFI [10] extends this model with dynamic binary instrumentation, and gpuFI4 [11] further refines campaign design and site classification. These systems are effective for real-hardware studies, but their reliance on backend-specific representations prevents natural alignment of equivalent faults across CUDA, HIP, and SYCL toolchains. Recent cross-layer studies [22], [23] make this limitation even clearer by showing that resilience conclusions can shift materially with the abstraction level and methodology used for injection. A second line of work similar to BitIR provides the compiler and application level foundation for our approach. LLFI [24], FlipIt [25], and REFINE [26] establish the viability of IR-level fault injection for CPU-based HPC workloads, showing that LLVM IR can support both portability and meaningful propagation analysis. GPU-oriented extensions move this reasoning closer to our setting. LLFI-GPU [27] brings LLVM based FI to GPU applications, Li et al. [28] study software-visible GPU error propagation, and GPU-Trident [29] develops efficient models of GPU error propagation. Related application- and compiler-level studies [30], [6], [31] further show that program structure, data representation, compiler transformation, and execution context can significantly affect resilience. These works justify LLVM IR as a meaningful analysis layer, but none establishes a unified framework that uses aligned LLVM IR fault sites to drive directly comparable campaigns across NVIDIA, AMD, and Intel GPUs on production systems. Many prior GPU fault injection studies rely on statistical or randomized sampling of fault locations for tractability [8], [9], [10], [11], which is a practical design choice for large campaigns but can miss structured divergence concentrated in specific opcodes, site classes, or workload contexts. For crossvendor comparison, this limitation is especially important. If aligned faults are sampled sparsely, backend-specific differences may be underrepresented or missed entirely. BitIR evaluates the complete aligned injection space for each retained benchmark rather than doing any sampling, preserving finegrained comparability across vendors. Our outcome classification follows the standard masked–

SDC–failure taxonomy established in architectural resilience studies [1], [5], with refinements for GPU workloads following Kalra et al. [6]. Unlike prior approaches that rely on application-reported status, BitIR classifies all outcomes against golden references, enabling consistent interpretation across vendor runtime systems. We additionally distinguish HANG from HARD FAILURE, which proves important in cross-vendor analysis. Taken together, prior work establishes the importance of GPU resilience analysis [3], [2], [4], [7], the value of realhardware fault injection [8], [9], [10], [11], [22], and the usefulness of higher-level program representations for studying fault propagation [24], [25], [26], [28], [6], [31]. These directions build on broader architectural and system-level reliability studies [1], [5], [20], [21]. What remains missing is a system that simultaneously provides cross architecture fault modeling at the LLVM IR level, execution on real production GPU hardware, and direct cross-vendor comparability through aligned injection sites. BitIR is designed to fill that gap. VIII. C ONCLUSION We presented BitIR, an LLVM IR-based fault injection framework for cross-architecture resilience analysis of heterogeneous GPU applications. By injecting semantically aligned single-bit faults before backend lowering, BitIR enables direct comparison of software-visible fault behavior across NVIDIA, Intel, and AMD GPUs on three leadership-class supercomputers under a shared fault model. Our campaigns show that resilience is not backend-invariant. The same aligned fault can be masked on one platform, manifest as silent data corruption on another, and surface as overt failure on a third. These differences are especially pronounced for memory-access, addressgeneration, pointer-bearing, and integer/control-bearing sites, and vary substantially by workload, underscoring the need for backend-aware and workload-aware fault mitigation. Our results also have direct implications for resilience practice. Backend-specific behaviors require different mitigation priorities: rapid recovery for NVIDIA, output validation for AMD, and timeout enforcement with hang detection for Intel, as well as workload structure compounds these differences. Our campaigns on Aurora further surface latent system-level vulnerabilities; a previously undetected issue in Intel’s GPU software stack is identified with the ALCF operations team, who subsequently deployed a fix on Aurora. The implementation and datasets will be released as open source on GitHub upon acceptance.3 Future work will extend BitIR to multi-bit and bursterror fault scenarios, and apply the cross-backend patterns identified here to guide backend-aware mitigation design. We also plan to extend the evaluation to multi-kernel and full application workloads to determine how larger program state and deeper execution structure affect cross-backend masking and propagation. 3 https://github.com/SPEAR-UIC/BitIR

ACKNOWLEDGMENT We acknowledge the use of computational resources provided by the Argonne Leadership Computing Facility (ALCF), the Oak Ridge Leadership Computing Facility (OLCF), and other supporting computing facilities. This work was supported in part by the U.S. National Science Foundation under Grants Nos. OAC-2402901 and CCF2515009 and in part by the U.S. Department of Energy under Contract No. DE-SC0024271. We also acknowledge support from the U.S. Department of Energy, Office of Science, under Grant No. DE-SC0023524 through the Chicagoland Computational Traineeship in High Energy Particle Physics Fellowship. R EFERENCES [1] S. S. Mukherjee, M. J. Kontz, and S. K. Reinhardt, “The soft error problem: An architectural perspective,” in Proceedings of the 11th International Symposium on High-Performance Computer Architecture (HPCA), 2005, pp. 243–247, 10.1109/HPCA.2005.41. [2] D. A. G. de Oliveira, L. L. Pilla, T. Santini, and P. Rech, “Evaluation and mitigation of radiation-induced soft errors in graphics processing units,” IEEE Trans. Comput., vol. 65, no. 3, p. 791–804, Mar. 2016, 10.1109/TC.2015.2444855. [3] J. Tan, N. Goswami, T. Li, and X. Fu, “Analyzing soft-error vulnerability on gpgpu microarchitecture,” in 2011 IEEE International Symposium on Workload Characterization (IISWC), 2011, pp. 226–235, 10.1109/IISWC.2011.6114182. [4] D. Tiwari et al., “Understanding gpu errors on large-scale hpc systems and the implications for system design and operation,” in Proceedings of the IEEE International Symposium on High Performance Computer Architecture (HPCA), 2015, pp. 331–342, 10.1109/HPCA.2015.7056044. [5] G. A. Reis, J. Chang, N. Vachharajani, R. Rangan, and D. I. August, “Design and evaluation of hybrid fault-detection systems,” ACM Transactions on Architecture and Code Optimization, 2005, 10.1145/1080695.1069983. [6] C. Kalra, F. Previlon, N. Rubin, and D. Kaeli, “Armorall: Compilerbased resilience targeting gpu applications,” ACM Trans. Archit. Code Optim., vol. 17, no. 2, May 2020, 10.1145/3382132. [7] A. Vallero, S. Tselonis, D. Gizopoulos, and S. Di Carlo, “Multi-faceted microarchitecture level reliability characterization for nvidia and amd gpus,” in 2018 IEEE 36th VLSI Test Symposium (VTS), 2018, pp. 1–6, 10.1109/VTS.2018.8368665. [8] B. Fang, K. Pattabiraman, M. Ripeanu, and S. Gurumurthi, “Gpu-qin: A methodology for evaluating the error resilience of gpgpu applications,” in 2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), 2014, pp. 221–230, 10.1109/ISPASS.2014.6844486. [9] S. K. S. Hari, T. Tsai, M. Stephenson, S. W. Keckler, and J. Emer, “ SASSIFI: An architecture-level fault injection tool for GPU application resilience evaluation ,” in 2017 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). Los Alamitos, CA, USA: IEEE Computer Society, Apr. 2017, pp. 249–258, 10.1109/ISPASS.2017.7975296. [10] T. Tsai, S. K. S. Hari, M. Sullivan, O. Villa, and S. W. Keckler, “Nvbitfi: Dynamic fault injection for gpus,” in 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2021, pp. 284–291, 10.1109/DSN48987.2021.00041. [11] D. Sartzetakis, G. Papadimitriou, and D. Gizopoulos, “gpufi-4: A microarchitecture-level framework for assessing the cross-layer resilience of nvidia gpus,” in 2022 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), 2022, pp. 35– 45, 10.1109/ISPASS55109.2022.00004. [12] NVIDIA Corporation, CUDA C++ Programming Guide, 2024, accessed: 2026-02-05. [Online]. Available: https://docs.nvidia.com/ cuda/cuda-c-programming-guide/ [13] Intel Corporation, Intel oneAPI Programming Guide, 2024, accessed: 2026-02-12. [Online]. Available: https://www.intel.com/content/www/ us/en/developer/tools/oneapi/programming-guide.html

[14] Advanced Micro Devices, Inc., HIP Programming Guide, 2024, accessed: 2026-02-12. [Online]. Available: https://rocmdocs.amd.com/ projects/HIP/en/latest/ [15] C. Lattner and V. Adve, “Llvm: a compilation framework for lifelong program analysis & transformation,” in International Symposium on Code Generation and Optimization, 2004. CGO 2004., 2004, pp. 75–86, 10.1109/CGO.2004.1281665. [16] Oak Ridge National Laboratory, “Hecbench: Heterogeneous computing benchmark suite,” https://github.com/ORNL/HeCBench, 2024. [17] A. Moody, G. Bronevetsky, K. Mohror, and B. R. de Supinski, “Design, modeling, and evaluation of a scalable multi-level checkpointing system,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC), 2010, 10.1109/SC.2010.18. [18] K.-H. Huang and J. A. Abraham, “Algorithm-based fault tolerance for matrix operations,” IEEE Trans. Comput., vol. 33, no. 6, p. 518–528, Jun. 1984, 10.1109/TC.1984.1676475. [19] Z. Chen, “Online-abft: an online algorithm based fault tolerance scheme for soft error detection in iterative methods,” vol. 48, no. 8. New York, NY, USA: Association for Computing Machinery, Feb. 2013, p. 167–176, 10.1145/2517327.2442533. [20] V. Sridharan, N. DeBardeleben, S. Blanchard, K. B. Ferreira, J. Stearley, J. Shalf, and S. Gurumurthi, “Memory errors in modern systems: The good, the bad, & the ugly,” vol. 50, no. 4. New York, NY, USA: Association for Computing Machinery, Mar. 2015, p. 297–310, 10.1145/2775054.2694348. [21] C. D. Martino, Z. Kalbarczyk, R. K. Iyer, F. Baccanico, J. Fullop, and W. Kramer, “Lessons learned from the analysis of system failures at petascale: The case of blue waters,” in Proceedings of the 2014 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, ser. DSN ’14. USA: IEEE Computer Society, 2014, p. 610–621, 10.1109/DSN.2014.62. [22] F. F. d. Santos, S. K. S. Hari, P. M. Basso, L. Carro, and P. Rech, “Demystifying gpu reliability: Comparing and combining beam experiments, fault simulation, and profiling,” in 2021 IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2021, pp. 289–298, 10.1109/IPDPS49936.2021.00037. [23] L. Yang, G. Papadimitriou, D. Sartzetakis, A. Jog, E. Smirni, and D. Gizopoulos, “Probing weaknesses in gpu reliability assessment: A cross-layer approach,” in 2024 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), 2024, pp. 331– 333, 10.1109/ISPASS61541.2024.00048. [24] Q. Lu, M. Farahani, J. Wei, A. Thomas, and K. Pattabiraman, “Llfi: An intermediate code-level fault injection tool for hardware faults,” in Proceedings of the 2015 IEEE International Conference on Software Quality, Reliability and Security, ser. QRS ’15. USA: IEEE Computer Society, 2015, p. 11–16, 10.1109/QRS.2015.13. [25] J. Calhoun, L. Olson, and M. Snir, “Flipit: An llvm based fault injector for hpc,” in Revised Selected Papers, Part I, of the Euro-Par 2014 International Workshops on Parallel Processing - Volume 8805. Berlin, Heidelberg: Springer-Verlag, 2014, p. 547–558, 10.1007/978-3-31914325-5 47. [26] G. Georgakoudis, I. Laguna, D. S. Nikolopoulos, and M. Schulz, “Refine: realistic fault injection via compiler-based instrumentation for accuracy, portability and speed,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, ser. SC ’17. Association for Computing Machinery, 2017, 10.1145/3126908.3126972. [27] D. S. Lab, “Llfi-gpu: Llvm-based fault injection for gpu applications,” https://github.com/DependableSystemsLab/LLFI-GPU. [28] G. Li, K. Pattabiraman, C.-Y. Cher, and P. Bose, “Understanding error propagation in gpgpu applications,” in SC ’16: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2016, pp. 240–251, 10.1109/SC.2016.20. [29] A. R. Anwer, G. Li, K. Pattabiraman, M. Sullivan, T. Tsai, and S. K. S. Hari, “Gpu-trident: Efficient modeling of error propagation in gpu programs,” in SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, 2020, pp. 1–15, 10.1109/SC41405.2020.00092. [30] C. Kalra, F. Previlon, X. Li, N. Rubin, and D. Kaeli, “Prism: predicting resilience of gpu applications using statistical methods,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage, and Analysis, ser. SC ’18. IEEE Press, 2019, 10.1109/SC.2018.00072.

[31] F. F. D. Santos, L. Carro, F. Vella, and P. Rech, “Assessing the impact of compiler optimizations on gpus reliability,” ACM Trans. Archit. Code Optim., vol. 21, no. 2, Feb. 2024, 10.1145/3638249.

Related documents

• BitIR: Cross-Architecture Fault Injection for Resilience Analysis of Heterogeneous GPU Applications#1199311
• From Custom-Fit to Portable: Bridging the Gap Between Synthesized and Engineered GPU Query Execution#349706
• Deterministic LLM Inference Across GPU Kernels: Power-of-Two INT8 Quantization Scales and the Limits of Tolerance-Based Conformance#819815
• Deterministic LLM Inference Across GPU Kernels: Power-of-Two INT8 Quantization Scales and the Limits of Tolerance-Based Conformance#809819
• FailBench: Evaluating Fault Tolerance Across Distributed Training Architectures#1217063