Pith. sign in

REVIEW 3 major objections 5 minor 32 references

DCE-LLM: Dead Code Elimination with Large Language Models

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read DCE-LLM claims that a small CodeBERT filter, an attribution-based line locator, and a fine-tuned LLM can together find, explain, and patch unused and unreachable code with F1 above 94%.

desk verdict A useful new dataset and a plausible dead-code elimination pipeline, undermined by an evaluation that compares against the same tools that generated the labels. read the letter →

arxiv 2506.11076 v1 pith:7J5SJ2SC submitted 2025-06-04 cs.SE

Minyu Chen , Guoqiang Li , Ling-I Wu , Ruibang Liu This is my paper · ORCID
classification cs.SE
keywords deadcodeeliminationunusedunreachablelargelanguagemodelsBERTattributionsupervisedfine-tuningstaticanalysis
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

This paper argues that dead code elimination can be automated end to end with a small neural filter plus a fine-tuned large language model, without relying on compilers or rule-based tools. The authors build the first large-scale annotated dataset of unused and unreachable code, and a pipeline that classifies, locates, explains, and patches dead code in Python, Java, and Go. On their test set the method reaches F1 above 94% for both dead-code types, exceeding GPT-4o by more than 30 F1 points on each type. If the result transfers to real codebases, it would close a gap left by IDEs and compilers, which miss most adversarially unreachable branches.

What carries the argument

The central mechanism is dead code attribution: for an n-line snippet C, a three-class classifier f returns a probability vector f(C); for each line, C_{-i} is formed by deleting the line if it is not a condition or by masking the condition with [mask], and the attribution value is a_i = max(f(C) - f(C_{-i}), 0), a two-dimensional vector for the unused and unreachable classes. These values rank lines, and a soft threshold max(a)/tau with tau=2 selects the suspect set fed to the LLM. This attribution signal is what lets a 512-token CodeBERT model locate dead-code lines without per-line training, by ranking lines according to how much removing or masking them lowers the classifier's dead-code probability.

What would settle it

Manually audit a random sample of AIDCE unused-code labels: if a substantial share of Vulture and IntelliJ reports are actually live code, or if the tools miss dead code a human would flag, the reported 94% F1 is an artifact of the label source. Separately, generate unreachable code from patterns outside the 62-pattern family, such as type-based contradictions, and re-run the pipeline; if F1 drops below the reported level, the method is pattern-sensitive.

Watch

Extended reading notes

Core claim

DCE-LLM establishes that the full dead-code-elimination loop—classifying code as normal, unused, or unreachable; locating the offending lines; explaining why they are dead; and emitting a corrected program—can be carried out by a learned pipeline. The key is to pair a CodeBERT classifier used as a high-recall filter with a per-line attribution step that distributes the classifier's prediction across lines by removing each line or masking each condition, then prompt a fine-tuned Qwen2-7B LLM with the ranked suspect lines. The paper reports F1 of 94.02 for unused and 96.65 for unreachable code on AIDCE, a 19,639-sample dataset built from CodeNet with IDE reports and 62 inserted unreachable patterns as labels. Human raters preferred DCE-LLM's explanations and repaired code over those of GPT-4o and IDEs, and a held-out Go test set shows F1 above 90% without retraining.

Load-bearing premise

The load-bearing premise is that the two annotation mechanisms—IDE reports taken as 100% accurate for unused code, and the 62 self-authored unreachable patterns—define dead code completely enough that high F1 on AIDCE means high F1 on dead code in the wild.

Editorial extensions

If this is right

  • Branches that defeat IDEs and compilers—after-return statements, covered branches, floor-based contradictions—are detected with F1 near 97%, so adversarial unreachable-code attacks become visible to a static, learned tool.
  • Developers receive line numbers, type labels, natural-language explanations, and repaired code in one pass, replacing IDE template warnings and manual tracing.
  • The same fine-tuned pipeline, without retraining, detects dead code in Go with F1 above 90%, suggesting cross-language generalization beyond Python and Java.
  • Because removing the pivot model in the ablation loses roughly 30 F1 points on unused code, the small high-recall filter is load-bearing, not optional.
  • The released dataset and code let others reproduce the reported numbers and extend the 62 unreachable patterns to new families.

Reading between the lines

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

  • The attribution procedure is a general recipe: any classifier over code can be turned into a line locator by leave-one-out deletion and condition masking, so the method could transfer to other line-level analyses such as fault localization or vulnerability explanation without line-level training.
  • Because unused-code labels inherit Vulture and IntelliJ reports that the paper assumes to be 100% accurate, and unreachable labels come from 62 templated insertions, the reported F1 is an upper bound tied to those label families; real-world dead code with different shapes may score lower.
  • If dead code is what confuses LLMs in vulnerability detection, running DCE-LLM as a pre-cleaner before other LLM-based code analyzers could harden them against dead-code injection attacks—an application the paper motivates but does not evaluate.
  • The gap over GPT-4o may partly reflect that GPT-4o receives no dead-code supervision; a larger model fine-tuned on the same SFT data could close part of the 30-point lead, so the comparison is between a tuned pipeline and untuned general models.
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

3 major / 5 minor

Summary. The paper proposes DCE-LLM, a dead code elimination framework that combines a CodeBERT-based pivot model with an attribution-based line selector and a fine-tuned LLM (Qwen2-7B) to classify, locate, explain, and repair dead code. The authors construct a new dataset, AIDCE, from CodeNet, labeling unused code with Vulture and IntelliJ IDEA and injecting 62 hand-crafted unreachable-code patterns. They report F1 scores above 94% for both unused and unreachable code, claiming a 30% improvement over GPT-4o and support for Python, Java, and Go.

Significance. If the empirical claims held, DCE-LLM would be a useful contribution as the first learning-based pipeline covering classification, localization, explanation, and repair for dead code. The design of the pivot model with line attribution is interesting, the cross-language support is a plus, and the authors provide their dataset and code. However, the evaluation as presented does not substantiate the headline claim of outperforming existing tools, because the unused-code labels are generated by the same tools used as baselines and the unreachable-code benchmark is entirely self-constructed from the authors' own patterns. The reported numbers are therefore measures of agreement with or generalization across the authors' data-generation process, not of superiority on naturally occurring dead code.

major comments (3)
  1. [Section 5.1 and Table 3] The unused-code evaluation is circular. The authors state that 'we use the reports from IDEs as the gold standard labels, assuming their accuracy to be 100%.' The same IDEs (Vulture and IntelliJ IDEA) are then included as baselines in Table 3, where they achieve 100.0 F1 by construction. The abstract's claim that DCE-LLM 'outperforms existing tools' is therefore unsupported for unused code; the 94.02 F1 merely reflects agreement with those IDE heuristics on the AIDCE test split. An independent gold standard, such as human-annotated dead code, is required to make a comparative claim.
  2. [Section 4.1.1 and Table 1] The unreachable-code benchmark is self-constructed. The authors designed 62 patterns for inserting unreachable code, used 32 for training and 30 for testing, and all test patterns come from this same hand-authored family. The 96.65 F1 therefore demonstrates generalization across these syntactic templates, not detection of naturally occurring unreachable code. To support the claim of 'advanced unreachability detection' over real-world dead code, the evaluation needs a test set of unreachable code from external sources or human-annotated real programs.
  3. [Tables 3–5] No error bars or significance tests are reported for any of the classification results. Given that the test sets are relatively small (e.g., the Java unreachable subset has 26 samples according to the detailed table) and the paper repeatedly claims 'significant' margins, the authors should provide confidence intervals or at least a statistical comparison, such as a paired bootstrap or McNemar's test. This is particularly important because the human evaluation of generation quality relies on only 40 total samples.
minor comments (5)
  1. [Section 4.1.1 and Appendix A] The dataset statistics are inconsistent. Table 2 reports a total of 19,639 samples, while Appendix A states train/validation/test splits of 15,043/1,889/1,891, which sum to 18,823. Please reconcile these numbers.
  2. [Table 1] The check/cross symbols in Table 1 are described as 'brown' and 'blue' in the text, but the arXiv version is monochrome. Use textual labels like 'Vulture: ✓' or a legend.
  3. [Introduction] The contribution list says the framework encompasses 'classification, location, exploration, and patching' but the body consistently uses 'explanation.' Please correct the terminology for consistency.
  4. [Section 5.2] The sentence 'IDEs for different languages are ensembled into a powerful baseline' is unclear. Specify how the IDE outputs are combined and why this is a fair baseline.
  5. [Limitation] The text reads 'we did not studied prompt engineering' — the grammar should be corrected; also, the claim 'no prompting method can bridge the over 30% F1 performance gap' is speculative and not supported by experiments.

Circularity Check

1 steps flagged · score 6.0 of 10

Unused-code evaluation is self-referential: IDE outputs are both the gold-standard labels and a Table 3 baseline, so the unused-code comparison against existing tools is by construction.

  1. self definitional [Section 4.1.1 Data Collection; Section 5.1 Evaluation Setup; Table 3]
    "By harnessing the power of static analysis, we treat the unused code identified by these tools as gold-standard labels for our dataset. ... Note that, for unused code, we use the reports from IDEs as the gold standard labels, assuming their accuracy to be 100%."

    The paper defines its unused-code labels as the reports of Vulture and IntelliJ IDEA, then enters the same IDEs as a baseline in Table 3, where they receive 100.0 F1 on unused code by construction because the test labels are their own reports. DCE-LLM is trained on those same IDE-derived labels, so its 94.02 F1 for unused code measures agreement with IDE heuristics, not detection of semantically unused code. The comparative claim that DCE-LLM 'outperforms existing tools' on unused code therefore reduces to comparing a learned mimic of IDE reports against the IDE reports themselves. The GPT-4o comparison is not itself circular, but it too is evaluated against the IDE-defined oracle rather than an independent dead-code ground truth.

full rationale

The unreachable-code evaluation is not circular in the same way: the authors explicitly hold out 30 of their 62 hand-authored insertion patterns for testing ('we only use 32 out of the 62 patterns for training, reserving the remaining 30 patterns exclusively for testing'), so the 96.65 F1 reflects generalization across unseen syntactic templates, albeit only within the authors' own synthetic pattern family. There is no load-bearing self-citation chain and no imported uniqueness theorem. The central defect is confined to the unused-code axis, where the operational definition of the target concept is identical to the baseline tool's output. Since that identity is stated in the paper and makes the IDE baseline trivially perfect, the unused-code comparison is partially circular by construction. The overall derivation pipeline (pivot model, attribution, LLM fine-tuning) retains independent technical content, so the score is 6 rather than higher.

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

The central claim rests on a self-constructed benchmark. The free parameters are the τ threshold and dataset composition ratios. The axioms include the defining assumption about dead code removal, the masking heuristic for conditions, and the assumption that IDE reports are perfect gold labels. No new physical or conceptual entities are introduced.

free parameters (2)
  • τ (soft threshold) = 2
    Used in Dead Code Locating to threshold attribution scores (max/τ) and build the candidate line set; no sensitivity analysis is reported, so it appears to be chosen by hand on the validation split.
  • Data composition ratio (normal:unused:unreachable) = 4:1:1 for AIDCE; 1:1:1 for SFT
    Chosen to approximate the dead code rate in CodeNet while balancing the unreachable class; affects class priors and reported precision/recall.
assumptions (4)
  • domain assumption Removing dead code does not affect program functionality, whereas removing functional code can create new dead code.
    Stated in Section 4.2.1 to justify using leave-one-out probability changes as attribution scores.
  • ad hoc to paper Masking a condition token prevents an unreachable condition from being classified as unreachable, and obscures normal conditions.
    Introduced in Section 4.2.1 for condition lines; no proof or empirical validation that masking behaves this way for all conditions.
  • ad hoc to paper IDE reports (Vulture and IntelliJ) are treated as 100% accurate gold labels for unused code.
    Section 5.1 explicitly assumes this, which makes the unused-code evaluation circular with respect to IDEs.
  • ad hoc to paper The 62 self-designed unreachable patterns cover sophisticated and realistic dead code and preserve original program functionality.
    Section 4.1.1 and Table 1; the test set uses held-out patterns from the same family, so generalization to real-world unreachable code is assumed, not measured.

how reviews work

0 comments
Cite this review

Pith. "Pith review of DCE-LLM: Dead Code Elimination with Large Language Models." pith.science (2026). https://pith.science/paper/7J5SJ2SC

@misc{pith2026250611076,
  author       = {Pith},
  title        = {Pith review of: DCE-LLM: Dead Code Elimination with Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7J5SJ2SC}},
  note         = {Machine review of arXiv:2506.11076}
}
read the original abstract

Dead code introduces several challenges in software development, such as increased binary size and maintenance difficulties. It can also obscure logical errors and be exploited for obfuscation in malware. For LLM-based code-related tasks, dead code introduces vulnerabilities that can mislead these models, raising security concerns. Although modern compilers and IDEs offer dead code elimination, sophisticated patterns can bypass these tools. A universal approach that includes classification, location, explanation, and correction is needed, yet current tools often require significant manual effort. We present DCE-LLM, a framework for automated dead code elimination using a small CodeBERT model with an attribution-based line selector to efficiently locate suspect code. LLMs then generate judgments and explanations, fine-tuned on a large-scale, annotated dead code dataset to provide detailed explanations and patches. DCE-LLM outperforms existing tools, with advanced unreachability detection, automated correction, and support for multiple programming languages. Experimental results show DCE-LLM achieves over 94% F1 scores for unused and unreachable code, significantly surpassing GPT-4o by 30%.

Figures

Figures reproduced from arXiv: 2506.11076 by the authors.

Figure 1
Figure 1. An illustrative Python method with dead code. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of the DCE-LLM approach. The yellow labels highlight the training step while the green labels [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. An illustrative Python method with dead code. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Human evaluation on explanation generation. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Human evaluation on code repairing. 5.3 Generation Quality To measure the quality of generated contents from DCE-LLM, we conduct a human evaluation of both explanations and repaired code. Three experienced programmers serve as voluntary annotators on 20 unused codes an…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 24 canonical work pages

  1. [1]

    Nour AlAbwaini, Amal Aldaaje, Tamara Jaber, Mohammad Abdallah, and Abdelfatah Tamimi. 2018. Using program slicing to detect the dead code. In 2018 8th International Conference on Computer Science and Information Technology (CSIT), pages 230--233. IEEE

    work page 2018

  2. [2]

    Seshia, and Alvin Cheung

    Sahil Bhatia, Jie Qiu, Niranjan Hasabnis, Sanjit A. Seshia, and Alvin Cheung. 2024. https://openreview.net/forum?id=spwE9sLrfg Verified code transpilation with LLM s . In The Thirty-eighth Annual Conference on Neural Information Processing Systems

    work page 2024

  3. [3]

    Hidde Boomsma, BV Hostnet, and Hans-Gerhard Gross. 2012. Dead code elimination for web systems written in php: Lessons learned from an industry case. In 2012 28th IEEE International Conference on Software Maintenance (ICSM), pages 511--515. IEEE

    work page 2012

  4. [4]

    Yih-Fam Chen, Emden R Gansner, and Eleftherios Koutsofios. 1998. A c++ data model supporting reachability analysis and dead code detection. IEEE Transactions on Software Engineering, 24(9):682--694

    work page 1998

  5. [5]

    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 languages. In Findings of the Association for Computational Linguistics: EMNLP 2020, pages 1536--1547

    work page 2020

  6. [6]

    Fengjuan Gao, Yu Wang, and Ke Wang. 2023. Discrete adversarial attack to models of code. Proceedings of the ACM on Programming Languages, 7(PLDI):172--195

    work page 2023

  7. [7]

    Hojae Han, Jaejin Kim, Jaeseok Yoo, Youngwon Lee, and Seung-won Hwang. 2024. Archcode: Incorporating software requirements in code generation with large language models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 13520--13552

    work page 2024

  8. [8]

    Edward J Hu, yelong shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen. 2022. https://openreview.net/forum?id=nZeVKeeFYf9 Lo RA : Low-rank adaptation of large language models . In International Conference on Learning Representations

    2022

Show all 32 references
  1. [9]

    IDEA IntelliJ. 2011. the most intelligent java ide. JetBrains [online].[cit. 2016-02-23]. Dostupn \'e z: https://www. jetbrains. com/idea/\# chooseYourEdition

    2011

  2. [10]

    Llm-assisted code cleaning for training accurate code generators

    Naman Jain, Tianjun Zhang, Wei-Lin Chiang, Joseph E Gonzalez, Koushik Sen, and Ion Stoica. Llm-assisted code cleaning for training accurate code generators. In The Twelfth International Conference on Learning Representations

  3. [11]

    Avishree Khare, Saikat Dutta, Ziyang Li, Alaia Solko-Breslin, Rajeev Alur, and Mayur Naik. 2023. Understanding the effectiveness of large language models in detecting security vulnerabilities. arXiv preprint arXiv:2311.16169

    2023 arXiv

  4. [12]

    Siwon Kim, Jihun Yi, Eunji Kim, and Sungroh Yoon. 2020. Interpretation of nlp models through input marginalization. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pages 3154--3167

    2020

  5. [13]

    Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph Gonzalez, Hao Zhang, and Ion Stoica. 2023. Efficient memory management for large language model serving with pagedattention. In Proceedings of the 29th Symposium on Operating Systems Princip...

    2023

  6. [14]

    Haochen Li, Xin Zhou, and Zhiqi Shen. 2024. Rewriting the code: A simple method for large language model augmented code search. arXiv preprint arXiv:2401.04514

    2024 arXiv

  7. [15]

    Jiwei Li, Will Monroe, and Dan Jurafsky. 2016. Understanding neural networks through representation erasure. arXiv preprint arXiv:1612.08220

    2016 arXiv

  8. [16]

    Ivano Malavolta, Kishan Nirghin, Gian Luca Scoccia, Simone Romano, Salvatore Lombardi, Giuseppe Scanniello, and Patricia Lago. 2023. Javascript dead code identification, elimination, and empirical assessment. IEEE Transactions on Software Engineering, 49(7):3692--3714

    2023

  9. [17]

    Edoardo Mosca, Ferenc Szigeti, Stella Tragianni, Daniel Gallagher, and Georg Groh. 2022. Shap-based explanation methods: a review for nlp interpretability. In Proceedings of the 29th international conference on computational linguistics, pages 4593--4603

    2022

  10. [18]

    Giang Nguyen, Daeyoung Kim, and Anh Nguyen. 2021. The effectiveness of feature attribution methods and its correlation with automatic evaluation scores. Advances in Neural Information Processing Systems, 34:26422--26436

    2021

  11. [19]

    Ruchir Puri, David S Kung, Geert Janssen, Wei Zhang, Giacomo Domeniconi, Vladimir Zolotov, Julian Dolby, Jie Chen, Mihir Choudhury, Lindsey Decker, Veronika Thost, Luca Buratti, Saurabh Pujar, Shyam Ramji, Ulrich Finkler, Susan Malaika, and Frederick Reiss. 2021. https://openr...

    2021

  12. [20]

    Simone Romano and Giuseppe Scanniello. 2018. Exploring the use of rapid type analysis for detecting the dead method smell in java code. In 2018 44th Euromicro conference on software engineering and advanced applications (SEAA), pages 167--174. IEEE

    2018

  13. [21]

    Simone Romano, Giuseppe Scanniello, Carlo Sartiani, and Michele Risi. 2016. A graph-based approach to detect unreachable methods in java software. In Proceedings of the 31st Annual ACM symposium on applied computing, pages 1538--1541

    2016

  14. [22]

    Simone Romano, Christopher Vendome, Giuseppe Scanniello, and Denys Poshyvanyk. 2020. https://doi.org/10.1109/TSE.2018.2842781 A multi-study investigation into dead code . IEEE Transactions on Software Engineering, 46(1):71--99

    2020

  15. [23]

    Vulture, find dead python code

    Jendrik Seipp. Vulture, find dead python code. https://github.com/jendrikseipp/vulture/

  16. [24]

    Hao Tang, Keya Hu, Jin Peng Zhou, Si Cheng Zhong, Wei-Long Zheng, Xujie Si, and Kevin Ellis. 2024 a . https://openreview.net/forum?id=o863gX6DxA Code repair with LLM s gives an exploration-exploitation tradeoff . In The Thirty-eighth Annual Conference on Neural Information Pro...

    2024

  17. [25]

    Bissyand \'e

    Xunzhu Tang, Kisub Kim, Yewei Song, Cedric Lothritz, Bei Li, Saad Ezzini, Haoye Tian, Jacques Klein, and T \'e gawend \'e F. Bissyand \'e . 2024 b . Codeagent: Autonomous communicative agents for code review

    2024

  18. [26]

    Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, and Xiangyu Zhang. 2024. https://doi.org/10.18653/v1/2024.findings-emnlp.217 Sanitizing large language models in bug detection with data-flow . In Findings of the Association for Computational Linguistics: EMNLP 2024, pages 379...

    2024 doi

  19. [27]

    Xing Wang, Yingzhou Zhang, Lian Zhao, and Xinghao Chen. 2017. Dead code detection method based on program slicing. In 2017 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), pages 155--158. IEEE

    2017

  20. [28]

    Coeditor: Leveraging repo-level diffs for code auto-editing

    Jiayi Wei, Greg Durrett, and Isil Dillig. Coeditor: Leveraging repo-level diffs for code auto-editing. In The Twelfth International Conference on Learning Representations

  21. [29]

    Aashish Yadavally, Yi Li, Shaohua Wang, and Tien N Nguyen. 2024. A learning-based approach to static program slicing. Proceedings of the ACM on Programming Languages, 8(OOPSLA1):83--109

    2024

  22. [30]

    Aidan ZH Yang, Claire Le Goues, Ruben Martins, and Vincent Hellendoorn. 2024. Large language models for test-free fault localization. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, pages 1--12

    2024

  23. [31]

    Yuze Zhao, Zhenya Huang, Yixiao Ma, Rui Li, Kai Zhang, Hao Jiang, Qi Liu, Linbo Zhu, and Yu Su. 2024. https://doi.org/10.18653/v1/2024.findings-acl.973 R e P air: Automated program repair with process-based feedback . In Findings of the Association for Computational Linguistic...

    2024 doi

  24. [32]

    Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye, Zheyan Luo, Zhangchi Feng, and Yongqiang Ma. 2024. http://arxiv.org/abs/2403.13372 Llamafactory: Unified efficient fine-tuning of 100+ language models . In Proceedings of the 62nd Annual Meeting of the Association for Compu...

    2024 arXiv

Pith tools

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