Pith. sign in

REVIEW 4 major objections 6 minor 32 references

SimP: Unifying Syntax- and Semantic-Guided Techniques for Efficient Program Reduction

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read SimP claims that pairing syntax-guided deletion with LLM-based semantic reduction collapses the long-tail slowdown of program reducers, cutting average reduction time by 1.75x while keeping output size comparable.

desk verdict A plausible hybrid reducer whose architecture is well supported by ablation, but the headline 1.75x speedup is tuned on the same benchmarks it is measured on. read the letter →

arxiv 2608.08352 v1 pith:ZCJIIVHO submitted 2026-08-08 cs.PL

Ye Xiong , Xiangyu Gao , Qiaochu Chen , Mingyu Li , Haibo Chen This is my paper · ORCID
classification cs.PL
keywords programreductioncompilerbugsmiscompilationlargelanguagemodelssyntax-guidedsemantic-guidedlong-taildetectionhybrid
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that modern program reducers waste most of their runtime in a long tail: after an initial phase of fast bulk deletion, local AST-level edits stall, and hours are spent removing a handful of tokens. SimP detects that stall at runtime and hands the program to two LLM-based stages, one that reasons about the bug-triggering semantics and synthesizes a smaller program, and one that rewrites the program into a form the deletion reducer can shrink further. On 23 real-world miscompilation benchmarks, SimP finishes with a 1.75x geometric-mean speedup over the faster of Perses and LPR, up to 2.55x, while final programs stay under 60 lines of code and LLM cost stays below $0.50 per benchmark. The core claim is that syntax-guided deletion is fast early and semantic reasoning is what breaks the logjam late, so combining them at the right switch point is faster than either paradigm alone.

What carries the argument

The central mechanism is the long-tail detector, a runtime score $\mathit{score}_t = r_t + p\cdot c_t$, where $r_t = \mathit{token}_t/\mathit{token}_0$ is the remaining token ratio and $c_t = (\mathit{token}_{t(1-j\%)} - \mathit{token}_t)/(\mathit{token}_0 - \mathit{token}_t)$ is recent reduction progress normalized by total reduction achieved; SimP switches when $\mathit{token}_t \le \lambda$ and $\mathit{score}_t \le K$. Around this switch, two LLM stages do the heavy lifting: a semantic reducer that mines contrastive positive and negative examples from the prior Perses run, follows a four-step reasoning guide, and uses best-of-$N$ selection with $N=6$, and a mutator that applies one of five single-strategy rewrite families region by region, filters candidates by bug preservation, and synthesizes surviving mutations back into one program.

What would settle it

Take a held-out suite of miscompilation bugs that was not used in any threshold or prompt tuning, run SimP with the appendix's fixed parameters against Perses and LPR, and measure end-to-end time to convergence; if the geometric-mean speedup over the better baseline is near 1x, or SimP often leaves outputs far above 60 lines, the paper's central claim is refuted.

Watch

Extended reading notes

Core claim

SimP's central discovery is that the long-tail slowdown of syntax-guided reducers is not a fixed cost but a detectable phase transition, and that LLM-driven global edits are the right tool once local AST edits stop paying. With a lightweight runtime detector, the reducer switches from Perses-style deletion to a semantic LLM reducer that produces multiple candidate reductions and keeps the smallest one that still triggers the bug, plus a syntax-guided LLM mutator that canonicalizes declarations, inlines functions, and flattens control flow. The resulting workflow reaches smaller programs in less time than either pure syntax-guided reduction or pure naive LLM reduction, and the ablation study shows that removing any component measurably degrades output quality.

Load-bearing premise

The load-bearing premise is that the long-tail detector thresholds and the prompt templates, tuned with access to the same 23 benchmarks used for evaluation, will keep working on unseen programs rather than being overfit to those benchmarks.

Editorial extensions

If this is right

  • Developers can expect hard miscompilation bugs to be reduced in about an hour less per case on average, with the worst cases dropping from over seven hours to roughly 100 minutes.
  • Final reduced programs remain small enough for direct human inspection, under 60 lines of code on all 23 benchmarks, with no single reducer consistently producing the smallest output.
  • The monetary cost of LLM calls stays below $0.50 per benchmark, so the hybrid strategy is practical for routine use rather than a research luxury.
  • Ablations show each component earns its place: removing the semantic reducer enlarges outputs by about 47% on average, removing the mutator by about 50%, and removing Perses by about 41%, so the hybrid interaction rather than any single stage delivers the result.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: the long-tail detector could serve as a standalone early-stopping signal for existing reducers even without LLMs, handing off to a human or a more expensive search at the moment local edits begin to stall.
  • Editorial inference: because the switching thresholds and prompt templates were optimized with access to the same 23 benchmarks used in the evaluation, a held-out suite is needed before the 1.75x average speedup can be treated as a general property of the method rather than of the tuned configuration.
  • Editorial inference: the single-strategy mutation design suggests a testable extension to other structured artifacts, such as SMT formulas, database queries, or configuration files, where local edits also stall and global semantic reasoning may help.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. SimP is a hybrid program reduction framework that combines traditional syntax-guided deletion (based on Perses) with two LLM-driven components: a semantic-guided reducer that synthesizes smaller bug-preserving programs, and a syntax-guided mutator that rewrites the program into a form more amenable to further deletion. A runtime detector (§4.1.1) identifies the long-tail phase of reduction and triggers the switch to the LLM stages. The paper evaluates SimP on 23 real-world miscompilation benchmarks, reporting a 1.75x geometric-mean speedup over the per-benchmark better of Perses and LPR, comparable final reduction sizes, and less than $0.50 LLM cost per benchmark. An ablation study attributes the gains to both the hybrid architecture and the structured prompt design.

Significance. If the reported results hold, SimP addresses a practically important bottleneck: syntax-guided reducers spend most of their runtime in a long tail of diminishing returns. The architectural insight—combining cheap rule-based deletion with LLM-based coordinated edits—is well motivated by the three observations in §3, and the ablation study provides evidence that each component contributes. The paper also ships an artifact and uses public benchmarks, which supports reproducibility. The main limitation is that the quantitative speedup is measured on the same benchmarks used to tune the detector thresholds and prompts, and the evaluation lacks sensitivity analysis and error bars; until that is addressed, the exact speedup numbers should be treated as indicative rather than definitive.

major comments (4)
  1. [§5.2.1, §4.1.1, §4.2.2] The central efficiency claim—a 1.75x geometric-mean speedup—is measured on the same 23 benchmarks used to set the long-tail detector thresholds (λ, K, p, j) and the DSPy-optimized prompt templates. The paper does not report a held-out benchmark split, a sensitivity analysis over these parameters, or repeated runs with confidence intervals. Because the detector and prompt pair determines when and how the LLM stages take over, the numeric speedup may be partly tuned to this specific suite and could be externally fragile. Please provide either a sensitivity analysis showing stable performance across plausible parameter choices, a holdout evaluation on additional benchmarks, or a clear argument for why the current parameters are not overfit to the evaluation set.
  2. [§4.1.1] The formula for c_t is ambiguous: the numerator 'token_t(1−j%) − token_t' can be read as token_t multiplied by (1−j%) rather than as the token count at time t(1−j%) minus the token count at time t. Since this quantity is load-bearing for the long-tail detection, please clarify the notation and define the time-window endpoints precisely.
  3. [§5.3] The ablation conclusions that 'every component contributes measurably' are based on single runs per variant. Given the stochastic nature of LLM sampling, the reported differences (e.g., 50% smaller with the mutator, 47% larger without the reducer, 41% larger without Perses) should be accompanied by confidence intervals or repeated runs with different random seeds to rule out run-to-run variation.
  4. [§5.2.2] The claim that the size gap on gcc116906 (260 vs. 115 tokens) 'does not noticeably increase the difficulty of human inspection' is supported only by a single qualitative example. If the paper wishes to maintain this assertion as part of the 'comparable reduction quality' claim, it needs a more systematic evaluation—for example, multiple examples or a small human study—rather than one anecdotal instance.
minor comments (6)
  1. [§1] There is a typo in 'thesyntax-guided program reductioncategory'; also the sentence 'All these tools belong to the syntax-guided program reduction category' appears immediately after describing LPR, which is confusing because the preceding sentences discuss C-Reduce and ddSMT as well.
  2. [Figure 7 caption] The caption says 'We highlight in the code snippet that is mutated from the input program,' which is grammatically awkward; please rephrase to clearly state which parts are highlighted, and describe the green/red color coding in a way that remains legible in grayscale printing.
  3. [Author affiliations] Ye Xiong and Xiangyu Gao are listed with the same email address (xiangyug@cs.washington.edu); please correct this likely typographical error.
  4. [§5.1] The evaluation uses 'GPT-5.1' but does not specify the exact model identifier, access date, or inference API; please provide this information to support reproducibility.
  5. [§5.2.3] The statement that 'the per-benchmark cost difference is ≤$0.3' would benefit from having the per-benchmark costs tabulated, for example in the appendix table, so that the average is not the only reported statistic.
  6. [§5.1] The description of the benchmark provenance is thin: references [1] and [2] are artifact URLs, but the paper does not explain how the 23 benchmarks were selected from those artifacts or which inclusion criteria were applied; a brief sentence would clarify the evaluation scope.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found; SimP's efficiency claim is an empirical comparison against external baselines and is not derived from its own fitted parameters by construction.

full rationale

SimP's central claims are empirical comparisons rather than derivations from its own assumptions. The 1.75x speedup reported in §5.2.1 is measured against Perses [27] and LPR [31] on 23 benchmarks drawn from external artifacts (CReal and LegoFuzz, refs [1,2]), and all reduction candidates are validated by re-running the compiler and checking bug-triggering behavior (§4.2.3, §4.3.2). The long-tail detector thresholds in §4.1.1 and the DSPy-optimized prompts in §4.2.2 are engineering parameters; even if those values were selected using the same benchmark suite, that would be a generalization or overfitting concern, not circularity, because the reported speedup is not algebraically or definitionally forced by those parameters. No load-bearing step relies on a self-citation: the only author-affiliated reference is the anonymous artifact [4], and the cited baselines and benchmarks are external. The ablation study in §5.3 independently tests each component against the full system rather than assuming the design. No equation in the paper equates a fitted parameter to the measured outcome, and no 'prediction' is constructed from its own input. Therefore no circular step can be exhibited, and the paper receives a score of 0.

Assumptions & free parameters 6 free parameters · 4 assumptions · 0 invented entities

SimP introduces no new physical or formal entities. The free parameters are engineering thresholds and prompt design choices, with values deferred to the appendix. The axioms are standard assumptions in program reduction: oracle reliability, Perses correctness, LLM capability, and benchmark representativeness.

free parameters (6)
  • Long-tail token threshold lambda = not stated in main text (Appendix C)
    Guards against switching while the program still has bulk-removable code; hand-set.
  • Long-tail score threshold K = not stated in main text (Appendix C)
    Second switching condition; hand-set.
  • Weight p in score formula = not stated in main text (Appendix C)
    Balances remaining token ratio against recent progress in score_t = r_t + p*c_t.
  • Time-window fraction j% = not stated in main text (Appendix C)
    Defines the recent elapsed-time window in the c_t term.
  • Best-of-N candidate count N = 6
    Number of LLM reduction candidates sampled per semantic-reducer call.
  • Prompt templates optimized with DSPy = not stated; optimized with DSPy
    The four-step reasoning guide and mutator strategy prompts are optimized using DSPy, potentially on the evaluation benchmarks.
assumptions (4)
  • domain assumption The bug-triggering property can be reliably checked by compiling with two optimization configurations and comparing execution results.
    Used as the validation oracle in every reduction step (Section 2.1); if the oracle is flaky or the two executions differ for reasons unrelated to the compiler bug, preservation checks are unreliable.
  • domain assumption Perses's syntax-guided deletion is correct and its validity checks preserve the bug-triggering property.
    SimP builds both deletion phases on Perses (Section 4.1) and inherits its AST edit operations and validation.
  • domain assumption GPT-5.1 can follow the structured four-step reasoning guide and produce syntactically valid C programs that preserve the inferred bug semantics when validated.
    The semantic reducer (Section 4.2) relies on the LLM's ability to reason from contrastive examples; the paper validates this empirically only on the 23 benchmarks.
  • domain assumption The 23 benchmarks from the CReal and LegoFuzz artifacts are representative of real compiler miscompilation bugs.
    The evaluation (Section 5.1) uses only these benchmarks, and the paper generalizes from them to make a state-of-the-art claim.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SimP: Unifying Syntax- and Semantic-Guided Techniques for Efficient Program Reduction." pith.science (2026). https://pith.science/paper/ZCJIIVHO

@misc{pith2026260808352,
  author       = {Pith},
  title        = {Pith review of: SimP: Unifying Syntax- and Semantic-Guided Techniques for Efficient Program Reduction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZCJIIVHO}},
  note         = {Machine review of arXiv:2608.08352}
}
read the original abstract

Compiler bugs are pervasive in modern compiler systems, but the test programs that trigger them are often too large for practical debugging. Program reduction addresses this by minimizing test program size while preserving the original bug-triggering behavior. Existing approaches mainly rely on syntax-guided, rule-based deletion strategies that iteratively remove parts of the program in a trial-and-error manner. While effective in reduction quality, these approaches suffer from slow reduction speed. This paper presents SimP, a program reduction framework that combines traditional reduction with LLM-based syntax- and semantic-guided reduction. SimP leverages customized prompt design to guide the reduction process. SimP synergistically combines rule-based and LLM-based reduction stages to optimize the reduction performance. The results show that SimP improves reduction efficiency while achieving comparable reduction quality, with negligible LLM monetary cost.

Figures

Figures reproduced from arXiv: 2608.08352 by the authors.

Figure 1
Figure 1. State-of-the-art syntax-guided reducers can quickly remove bug-irrelevant code in the early stage, but their reduction speed gradually slows down later. Our ap￾proach (called SimP) reuses the efficient initial reduction of existing approaches until the long-tail is detected. It then switches to a hybrid mode that combines LLM-guided se￾mantic and syntactic reasoning with rule-based techniques to continue reduction. … view at source ↗
Figure 2
Figure 2. Long-tail phenomenon on the gcc107176 bench￾mark. The top row shows the full reduction trajectory of Perses, LPR, and C-Reduce; the bottom row enlarges the shaded long-tail region of each plot. Observation 1: Long-tail phenomenon affects the reduction speed. We record the procedure of existing program reduc￾tion tools (e.g., Perses [27], LPR [31], and C-Reduce [25]). Al￾though they can achieve high reduction speed d… view at source ↗
Figure 3
Figure 3. Cumulative counts of negative and positive vari￾ants generated by Perses on gcc107176. The gap between the two curves grows by more than an order of magnitude between the early and late phases of reduction. and positive programs is relatively small in the initial phase (≈544 in the first 10 minutes), but grows significantly as the reduction process proceeds, reaching ≈6276 by the end. This is because in early stages… view at source ↗
Figures from the paper (8 more)
Figure 5
Figure 5. Figure 5: shows the resulting workflow. SimP consists of three components: (1) a syntax-guided deletion reducer that handles early-stage reduction and includes a lightweight detector for the long-tail transition; (2) a semantic-guided LLM reducer that reasons about why the progr…
Figure 6
Figure 6. Figure 6: (a) Input bug-triggering program. (b) Compiler behaviors: -O3 produces an infinite loop, while -O0 operates normally. LLM semantically analyzes the behavior and gen￾erates an output program (c) with only for loops preserved. dereference operations, canonicalizing equiv…
Figure 7
Figure 7. Figure 7: Intermediate mutation results for the input program in [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 10
Figure 10. Figure 10: Distribution of final reduced-program size (in tokens) across the 23 benchmarks for Perses, LPR, and SimP. The three reducers produce outputs of comparable size, with no single reducer dominating across all benchmarks. every reduced program is under 60 LoC, which is c…
Figure 9
Figure 9. Figure 9: Cumulative distribution of end-to-end reduction time across the 23 benchmarks. SimP’s curve lies strictly to the left of Perses and LPR, corresponding to a 1.75× geometric-mean speedup over the better of the two. 5.2.2 Reduction size. We measure final reduction quality…
Figure 11
Figure 11. Figure 11: Qualitative comparison of reduced programs for gcc116906, the benchmark where SimP’s output is largest relative to LPR (260 vs. 115 tokens). Top: a compact schema abstracted from the highlighted fragments below. Bottom: the concrete LPR and SimP outputs that instantia…
Figure 12
Figure 12. Figure 12: Reduction trajectory on gcc107176, zoomed into the long-tail region of [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]
Figure 13
Figure 13. Figure 13: Ablation of SimP’s components across the 23 benchmarks. The syntax-guided mutator and the semantic reducer form a quality–speed trade-off, while Perses and the structured prompt design each independently improve reduction quality. • Without Perses: the Perses-based de…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 24 canonical work pages

  1. [1]

    CReal Artifact

    2024. CReal Artifact. Retrieved May 15, 2026 fromhttps://zenodo. org/records/10802596

    work page arXiv 2024

  2. [2]

    LegoFuzz Artifact

    2025. LegoFuzz Artifact. Retrieved May 15, 2026 fromhttps://zenodo. org/records/15761520

    work page arXiv 2025

  3. [3]

    GCC: GNU Compiler Collection

    2026. GCC: GNU Compiler Collection. Retrieved May 15, 2026 from https://gcc.gnu.org/

    work page 2026

  4. [4]

    SimP Artifact

    2026. SimP Artifact. Retrieved May 15, 2026 fromhttps://anonymous. 4open.science/r/SimP-1FE7/

    work page 2026

  5. [5]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al . 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774(2023)

    arXiv 2023

  6. [6]

    Xiao Bi, Deli Chen, Guanting Chen, Shanhuang Chen, Damai Dai, Chengqi Deng, Honghui Ding, Kai Dong, Qiushi Du, Zhe Fu, et al. 2024. Deepseek llm: Scaling open-source language models with longtermism. arXiv preprint arXiv:2401.02954(2024)

    arXiv 2024

  7. [7]

    Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, et al. 2014. P4: Programming protocol-independent packet processors.ACM SIGCOMM Computer Communication Review(2014)

    work page 2014

  8. [8]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374(2021)

    arXiv 2021

Show all 32 references
  1. [9]

    2018.{TVM}: An automated{End-to-End} optimizing compiler for deep learning

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, et al. 2018.{TVM}: An automated{End-to-End} optimizing compiler for deep learning. InUSENIX OSDI

    2018

  2. [10]

    Chris Cummins, Volker Seeker, Dejan Grubisic, Mostafa Elhoushi, Youwei Liang, Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Kim Hazelwood, Gabriel Synnaeve, et al. 2023. Large language models for compiler optimization.arXiv preprint arXiv:2309.07062(2023)

    2023 arXiv

  3. [11]

    Donaldson, Paul Thomson, Vasyl Teliman, Stefano Milizia, André Perez Maselco, and Antoni Karpiński

    Alastair F. Donaldson, Paul Thomson, Vasyl Teliman, Stefano Milizia, André Perez Maselco, and Antoni Karpiński. 2021. Test-case reduction and deduplication almost for free with transformation-based compiler testing. InACM PLDI

    2021

  4. [12]

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, et al. 2020. Codebert: A pre-trained model for programming and natural lan- guages. InFindings of the association for computational linguistics: EMNLP 2020

    2020

  5. [13]

    Daya Guo, Shuo Ren, Shuai Lu, Zhangyin Feng, Duyu Tang, Shujie Liu, Long Zhou, Nan Duan, Alexey Svyatkovskiy, Shengyu Fu, et al

  6. [14]

    Christian Gram Kalhauge and Jens Palsberg. 2019. Binary reduction of dependency graphs. InProceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    2019

  7. [15]

    Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Saiful Haq, Ashutosh Sharma, Thomas Joshi, Hanna Moazam, Heather Miller, et al. 2024. DSPy: compiling declara- tive language model calls into state-of-the-art pipelines. InInterna- tional Confere...

    2024

  8. [16]

    Gereon Kremer, Aina Niemetz, and Mathias Preiner. 2021. ddSMT 2.0: Better Delta Debugging for the SMT-LIBv2 Language and Friends. In International Conference on Computer-Aided Verification

    2021

  9. [17]

    Chris Lattner and Vikram Adve. 2004. LLVM: A compilation frame- work for lifelong program analysis & transformation. InInternational symposium on code generation and optimization (CGO)

    2004

  10. [18]

    Vu Le, Mehrdad Afshari, and Zhendong Su. 2014. Compiler validation via equivalence modulo inputs. InACM PLDI. ACM New York, NY, USA

    2014

  11. [19]

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrit- twieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al . 2022. Competition-level code generation with alphacode.Science(2022)

    2022

  12. [20]

    Vsevolod Livinskii, Dmitry Babokin, and John Regehr. 2020. Random testing for C and C++ compilers with YARPGen. InACM OOPSLA. ACM New York, NY, USA

    2020

  13. [21]

    Lopes, Juneyoung Lee, Chung-Kil Hur, Zhengyang Liu, and John Regehr

    Nuno P. Lopes, Juneyoung Lee, Chung-Kil Hur, Zhengyang Liu, and John Regehr. 2021. Alive2: bounded translation validation for LLVM. InACM PLDI

    2021

  14. [22]

    Ghassan Misherghi and Zhendong Su. 2006. HDD: hierarchical delta debugging. InACM/IEEE ICSE

    2006

  15. [23]

    Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2022. Codegen: An open large language model for code with multi-turn program synthesis. arXiv preprint arXiv:2203.13474(2022)

    2022 arXiv

  16. [24]

    Alexander Novikov, Ngân V˜u, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Ko- zlovskii, Francisco JR Ruiz, Abbas Mehrabian, et al. 2025. Alphaevolve: A coding agent for scientific and algorithmic discovery.arXiv preprint arXi...

    2025 arXiv

  17. [25]

    John Regehr, Yang Chen, Pascal Cuoq, Eric Eide, Chucky Ellison, and Xuejun Yang. 2012. Test-case reduction for C compiler bugs. InACM PLDI. 335–346

    2012

  18. [26]

    Fabian Ruffy, Jed Liu, Prathima Kotikalapudi, Vojtech Havel, Hanneli Tavante, Rob Sherwood, Vladyslav Dubina, Volodymyr Peschanenko, Anirudh Sivaraman, and Nate Foster. 2023. P4Testgen: An Extensible Test Oracle For P4. InACM SIGCOMM

    2023

  19. [27]

    Chengnian Sun, Yuanbo Li, Qirun Zhang, Tianxiao Gu, and Zhendong Su. 2018. Perses: Syntax-Guided Program Reduction. InACM/IEEE ICSE. 13 Ye Xiong, Xiangyu Gao, Jocelyn Qiaochu Chen, Mingyu Li, and Haibo Chen

    2018

  20. [28]

    Gemini Team, Rohan Anil, Sebastian Borgeaud, Jean-Baptiste Alayrac, Jiahui Yu, Radu Soricut, Johan Schalkwyk, Andrew M Dai, Anja Hauth, Katie Millican, et al. 2023. Gemini: a family of highly capable multi- modal models.arXiv preprint arXiv:2312.11805(2023)

    2023 arXiv

  21. [29]

    Yongqiang Tian, Xueyan Zhang, Yiwen Dong, Zhenyang Xu, Mengx- iao Zhang, Yu Jiang, Shing-Chi Cheung, and Chengnian Sun. 2023. On the Caching Schemes to Speed Up Program Reduction.ACM Trans. Softw. Eng. Methodol.(2023)

    2023

  22. [30]

    Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. 2011. Finding and understanding bugs in C compilers. InACM PLDI

    2011

  23. [31]

    Mengxiao Zhang, Yongqiang Tian, Zhenyang Xu, Yiwen Dong, Shin Hwei Tan, and Chengnian Sun. 2024. LPR: Large Language Models-Aided Program Reduction. InACM ISSTA. 14

    2024

  24. [2020]

    Graphcodebert: Pre-training code representations with data flow.arXiv preprint arXiv:2009.08366(2020)

    2020 arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.