TargetFuzz: Fuzzing for Compiler Optimizations

• TargetFuzz is a targeted fuzzing framework that directly tests compiler optimizations by mining grammar-level composition styles to reconstruct specific structural relations in code.
• It uses lightweight grammar annotations and synthesized mutations to adapt to new languages, enhancing optimization trigger throughput and coverage in systems like LLVM and MLIR.
• Evaluations show that TargetFuzz outperforms baseline fuzzers by up to 2.8x in throughput and uncovered multiple new bugs, demonstrating its effectiveness in targeted optimization testing.

TargetFuzz is a targeted fuzzing framework for compiler optimizations introduced in "Targeted Testing of Compiler Optimizations via Grammar-Level Composition Styles" (Zhou et al., 4 Dec 2025). It is designed for a setting in which existing fuzzers can generate syntactically valid programs yet still fail to exercise optimization logic because optimization pipelines are incomplete and many optimizations require specific structural relationships in the input program. Its central mechanism is to mine grammar-level "composition styles" from an optimization-relevant corpus and then rebuild those styles inside different contexts offered by a larger seed corpus through synthesized mutations. The system is grammar-based, adaptable to new languages through lightweight construct annotations, and was evaluated on LLVM and MLIR, where it improved coverage by 8% and 11% and triggered optimizations $2.8\times$ and $2.6\times$ compared to baseline fuzzers under the targeted fuzzing mode (Zhou et al., 4 Dec 2025).

1. Definition and conceptual scope

TargetFuzz targets individual compiler optimizations directly rather than relying only on canonical optimization pipelines such as clang -O3 (Zhou et al., 4 Dec 2025). In this design, the "target" is not merely a source location, a crash site, or a user-written fuzz harness, but an optimization or small group of optimizations whose triggering conditions are structurally constrained. The framework therefore belongs to targeted fuzzing, but in a sense distinct from location-directed greybox fuzzing and fuzz-target generation.

This distinction matters because the broader fuzzing literature uses related terminology in multiple ways. In directed greybox fuzzing, "targeted" often denotes guidance toward predefined program locations through online or offline analyses; for example, one line of work computes no-target-ahead prefixes and uses them in a specialized power schedule (Wüstholz et al., 2019), while another biases search using a distance metric over basic blocks together with structured mutation (Wang et al., 2020). A separate line of work treats target selection itself as an orthogonal design dimension and evaluates scoring functions over functions in terms of retrieval quality on crash corpora (Weissberg et al., 12 Feb 2025). By contrast, TargetFuzz does not rank suspicious source locations and does not primarily solve reachability to code sites. Its unit of targeting is optimization behavior, and its guidance signal is structural rather than distance-based (Zhou et al., 4 Dec 2025).

A further source of ambiguity is that "fuzz target" can also mean an executable harness, especially in work on automated fuzz target generation for C/C++ libraries (Kelly et al., 2019). TargetFuzz is not a harness generator in that sense. It operates on grammars, construct annotations, and compiler-facing program structure, and it is aimed at optimization testing rather than API harness synthesis (Zhou et al., 4 Dec 2025).

2. Motivation: limitations of pipeline-based optimization testing

The motivating claim is that pipeline-based fuzzing is insufficient for optimization testing because of both pipeline incompleteness and structural preconditions in the input space (Zhou et al., 4 Dec 2025). Optimization pipelines suffer from the phase-ordering problem: one pass can enable or preempt another, so a fixed sequence inevitably misses optimization interactions. The paper gives the example that early loop unrolling can prevent later vectorization. It also notes that many optimizations are simply not scheduled, even at aggressive optimization levels, and that this issue is more severe in modular systems such as MLIR, where optimizations are dialect-specific and no single canonical pipeline exercises everything (Zhou et al., 4 Dec 2025).

The empirical motivation is explicit. In the LLVM study, the authors report that in 4 hours of fuzzing with GrayC, 47.5% of optimization passes were entirely untested, and LLVM transformation-module line coverage was only 12.12% (Zhou et al., 4 Dec 2025). This is presented as evidence that whole-pipeline fuzzing leaves a large portion of optimization logic untouched even when the underlying fuzzer is strong on validity and general compiler exploration.

TargetFuzz addresses a second limitation: many optimizations only fire when the input program exhibits specific structural relations such as adjacent loops, nested loops, repeated expressions in different branches, ordered statements, or sibling constructs under a common ancestor (Zhou et al., 4 Dec 2025). Standard generators and mutators may produce valid programs yet still fail to reconstruct these relations systematically. TargetFuzz therefore treats optimization testing as a structure-reconstruction problem rather than only a coverage-maximization problem.

3. Composition styles, construct trees, and grammar annotations

The core abstraction in TargetFuzz is the composition style, a grammar-level structural relation over program constructs (Zhou et al., 4 Dec 2025). The framework defines a composition style as

$C = (R_c, (T_1, \ldots, T_k), T_{ctx}, p),$

where $R_c$ is a $k$-ary structural relation over constructs, $T_1,\ldots,T_k$ are the admissible types of the matched constructs, $T_{ctx}$ is the admissible type of the context construct, and $p$ is a set of additional predicates (Zhou et al., 4 Dec 2025). This formalization allows the system to encode not only raw syntactic adjacency but also context-sensitive structural constraints over constructs relevant to optimization logic.

The paper instantiates six concrete styles: Cousins, Nesting, Precedes, Balanced, Sequence, and Exists (Zhou et al., 4 Dec 2025). Cousins matches same-type constructs that share a common ancestor; Nesting matches same-type ancestor-descendant constructs; Precedes captures order within a shared context; Balanced matches similar constructs in different branches of an IF-ELSE; Sequence captures repeated patterns; and Exists captures the presence of a construct within a context (Zhou et al., 4 Dec 2025). The running Loop Fusion example is expressed through the Cousins style, where two adjacent loops under a function context form a fusible opportunity.

The structural layer is built from grammar annotations. TargetFuzz parses programs with an ANTLR grammar and then translates parse trees into construct trees that expose optimization-relevant abstractions such as LOOP, IF-ELSE, FUNCCALL, MEMREF, VECTOR, ARITHMETIC, and LOGICAL (Zhou et al., 4 Dec 2025). Some constructs correspond directly to grammar rules, while others are defined by custom predicates; the paper gives examples such as ARITH_EXPR_ and VECTOR_EXPR_ (Zhou et al., 4 Dec 2025). This design is intended to make the framework language-agnostic and especially suitable for ecosystems such as MLIR, where hand-maintained semantic generators are brittle.

The annotation burden is reported as modest: roughly 323 lines of annotations for C and 314 lines for MLIR, with the claim that onboarding a new language takes only a few hours (Zhou et al., 4 Dec 2025). This suggests that the portability claim rests on keeping optimization-facing semantics in the annotation layer rather than in hand-coded mutators.

4. Mining and reconstruction pipeline

The TargetFuzz workflow has three phases: parse and annotate, mine composition styles, and rebuild styles in new contexts (Zhou et al., 4 Dec 2025). In the first phase, both the optimization corpus and the seed corpus are parsed and converted into construct trees. In the second phase, the system scans the optimization-corpus construct trees for witnesses of composition-style matches. These witnesses need not already trigger the optimization; they serve as structural breadcrumbs associated with optimization-relevant code (Zhou et al., 4 Dec 2025). In the third phase, TargetFuzz synthesizes mutations and crossovers that rebuild the mined style inside seed-corpus programs.

The system defines four transformation families for style reconstruction.

Family	Operation
Replicate	Rebuilds a style using only recipient-program material by cloning an anchor construct
Move	Rebuilds a style using recipient material by moving an existing construct
Insert	Crosses donor constructs into the recipient context
Replace	Crosses donor constructs by replacing recipient constructs

Replicate and Move are recipient-only mutations; Insert and Replace are crossovers using donor material from the optimization corpus (Zhou et al., 4 Dec 2025). The intended effect is not arbitrary structural perturbation but deliberate reconstruction of an optimization-relevant relation under a different context. This is why the paper characterizes the approach as taking a structural relation that appears in optimization-adjacent code and rebuilding that relation in many new programs (Zhou et al., 4 Dec 2025).

A central technical problem is preserving scope and typing after structural edits. TargetFuzz addresses this with parameterized mutation driven by grammar annotations for USES_, DEFS_, and TYPES_ (Zhou et al., 4 Dec 2025). These annotations track declaration-use relationships, maintain in-scope bindings, and enforce type compatibility during rewrites. The paper states that a context contains matched constructs only when all uses in those constructs can be resolved to declarations within the context and types remain compatible (Zhou et al., 4 Dec 2025). This avoids reliance on hand-coded language semantics while still constraining mutations enough to keep programs executable for compiler testing.

5. Implementation and evaluation on LLVM and MLIR

TargetFuzz is implemented on top of Grammarinator in about 5360 LOC (Zhou et al., 4 Dec 2025). The evaluation covers LLVM and MLIR. Because both ecosystems contain over 200 passes, the study samples 37 LLVM optimizations and 26 MLIR optimizations spanning LLVM categories such as Scalar, Loop, InstCombine, and Interprocedural, and MLIR dialects such as affine, vector, arith, scf, async, gpu, and memref (Zhou et al., 4 Dec 2025). The optimization corpus consists of 100 valid programs per optimization pass, obtained with GPT-4o-mini from documentation, metadata, and source context, while the seed corpus contains 1059 C programs and 3601 MLIR programs (Zhou et al., 4 Dec 2025).

The main baselines are Grammarinator, SynthFuzz, GrayC, and MLIRSmith (Zhou et al., 4 Dec 2025). The evaluation uses two primary metrics: branch coverage on compiler code and optimization trigger throughput, defined as the number of successful optimization transformations triggered in a fixed time budget (Zhou et al., 4 Dec 2025). This separation is important because coverage alone does not necessarily reflect the quality of optimization testing.

In LLVM whole-pipeline mode, GrayC performs best overall and TargetFuzz ranks second, which the paper interprets as consistent with GrayC being highly tuned for C/C++ validity and whole-compiler exploration (Zhou et al., 4 Dec 2025). Under targeted fuzzing, however, TargetFuzz outperforms all baselines on Interprocedural, InstCombine, and Scalar optimizations, while SynthFuzz is reported as slightly better on Loop optimizations by about 0.7% (Zhou et al., 4 Dec 2025). In MLIR targeted mode, TargetFuzz achieves 9.7% higher coverage than Grammarinator and 11.2% higher than SynthFuzz, with particularly strong results on gpu and vector, while MLIRSmith achieves near-zero coverage because its hardcoded semantic generators are brittle under MLIR’s evolving ecosystem (Zhou et al., 4 Dec 2025).

The most prominent result concerns complementarity between targeted and pipeline fuzzing. Across 37 sampled LLVM optimizations, TargetFuzz tested all 37, whereas pipeline fuzzing missed 12 (Zhou et al., 4 Dec 2025). The paper therefore argues that targeted fuzzing and pipeline fuzzing are complementary rather than interchangeable. On optimization trigger throughput, TargetFuzz outperforms Grammarinator by 5.14x, SynthFuzz by 1.74x, and GrayC by 2.8x on LLVM, and it outperforms Grammarinator by 2.71x and SynthFuzz by 2.45x on MLIR (Zhou et al., 4 Dec 2025). The effect is strongest on harder-to-reach optimizations such as LoopFusion, DeadArgumentElimination, MergeFunctions, and GVNHoist, whose triggering conditions are structurally restrictive (Zhou et al., 4 Dec 2025).

The bug-finding study further reports 18 previously unknown bugs in LLVM and MLIR, including 10 optimization bugs and 2 backend bugs; it also reports 4 miscompilations and 14 crashes (Zhou et al., 4 Dec 2025). In an RQ4 analysis using Alive2, 8 optimizations were flagged for miscompilation, and the strongest composition styles were Precedes and Exists, with 5 optimizations discovered only by those styles (Zhou et al., 4 Dec 2025). The paper presents these findings as evidence that no single style-mutator pair suffices for optimization bugs because optimization logic is structurally diverse.

6. Position within targeted fuzzing research

TargetFuzz can be situated within a broader shift in fuzzing from undifferentiated exploration to explicit reasoning about what should be fuzzed and how that target notion should shape search (Weissberg et al., 12 Feb 2025). The 2025 systematization of directed-fuzzing target selection argues that target selection is an orthogonal design dimension and shows that simple software metrics can outperform common heuristics when the goal is to rank crash-relevant code (Weissberg et al., 12 Feb 2025). TargetFuzz is consistent with that broader framing, but it relocates the selection problem from suspicious code locations to optimization-relevant structures. Its scoring signal is not function-level relevance but the presence and reconstructability of composition styles (Zhou et al., 4 Dec 2025).

This also clarifies several common misconceptions. One misconception is that targeted fuzzing is reducible to distance guidance toward a code site. That description fits some systems, such as TOFU’s distance-guided target reachability on basic blocks (Wang et al., 2020) or online lookahead analysis for smart contracts (Wüstholz et al., 2019), but not TargetFuzz, whose target semantics are optimization-centric and grammar-level. A second misconception is that "target fuzzing" is primarily about selecting vulnerable functions or basic blocks before running a fuzzer. That characterization matches compile-time ranking pipelines such as FuzzDistill, which use features like call-graph connectivity, loops, allocations, and memory operations to prioritize code regions for directed fuzzing (Upadhyay, 2024). TargetFuzz does not predict vulnerability-prone regions; it reconstructs optimization-triggering program structure (Zhou et al., 4 Dec 2025).

A third misconception is that targeted fuzzing can be subsumed by stronger whole-pipeline fuzzing. The paper explicitly argues otherwise: pipeline fuzzing is useful for breadth, while TargetFuzz is useful for directly reaching optimization logic that standard pipelines omit or rarely trigger (Zhou et al., 4 Dec 2025). The reported result that targeted fuzzing exercised all 37 sampled LLVM optimizations while pipeline fuzzing missed 12 is the clearest formulation of that claim (Zhou et al., 4 Dec 2025).

In that sense, TargetFuzz represents a specialization of targeted fuzzing for compiler optimization validation. Its distinctive contribution is not a new distance metric or a new harnessing strategy, but a structural testing methodology: mine optimization-relevant composition styles, reconstruct them through synthesized grammar-level transformations, preserve scope and typing through parameterized mutation, and use targeted execution of individual passes to complement rather than replace pipeline-based testing (Zhou et al., 4 Dec 2025).