agentleFS
Sign inStart free
rainoftimerainoftime/pl-skills/dead-code-eliminator/SKILL.md

dead-code-eliminator

Skill17 starsChanged 9 months agoApache-2.0View on GitHub

Eliminate unreachable and unused code to reduce program size and improve performance.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Unreachable Code Elimination: Remove code that cannot be executed

    line 25
  2. Distinctive:

    Dead Variable Elimination: Remove computations of unused values

    line 26
  3. Distinctive:

    Dead Store Elimination: Remove writes that are never read

    line 27
  4. Distinctive:

    Dead Function Elimination: Remove functions that are never called

    line 28
  5. Distinctive:

    Run DCE after inlining to clean up unused parameters

    line 43
  6. Distinctive:

    Use SSA form for simpler liveness analysis

    line 45
  7. Distinctive:

    Run iteratively until fixpoint

    line 46
  8. Distinctive:

    When code size is not a concern

    line 84
  9. Distinctive:

    When side effects are unclear (volatile, I/O)

    line 86

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dead Code Eliminator

Dead code elimination (DCE) removes code that has no effect on program output, including unreachable code, unused computations, and redundant assignments. It is a fundamental optimization in compilers.

When to Use This Skill

  • Optimizing compiler passes
  • Reducing binary size
  • Improving cache utilization
  • Cleaning up generated code
  • Minifying code for distribution

What This Skill Does

  1. Unreachable Code Elimination: Remove code that cannot be executed
  2. Dead Variable Elimination: Remove computations of unused values
  3. Dead Store Elimination: Remove writes that are never read
  4. Dead Function Elimination: Remove functions that are never called
  5. Aggressive DCE: Iteratively remove dead code until fixpoint

Key Concepts

ConceptDescription
Dead CodeCode that has no effect on program output
Unreachable CodeCode that cannot be executed
Live VariableVariable that may be used later
Critical InstructionInstruction with side effects
FixpointState where no more changes occur

Tips

  • Run DCE after inlining to clean up unused parameters
  • Combine with constant propagation for better results
  • Use SSA form for simpler liveness analysis
  • Run iteratively until fixpoint
  • Be careful with memory-mapped I/O (appears dead)

Common Use Cases

  • Post-inlining cleanup
  • Tree shaking in JavaScript bundlers
  • Removing debug code in production
  • Optimizing generated code
  • Binary size reduction

Related Skills

  • constant-propagation-pass - Often combined with DCE
  • inline-expander - Creates dead code opportunities
  • dataflow-analysis-framework - Foundation for liveness
  • ssa-constructor - Simplifies analysis

Canonical References

ReferenceWhy It Matters
Muchnick, "Advanced Compiler Design and Implementation", Ch. 18 (1997)Comprehensive treatment
Click & Cooper, "Combining Analyses, Optimizing and Using Them" (1995)Modern DCE approach
LLVM Dead Code Elimination PassProduction implementation

Tradeoffs and Limitations

Approach Tradeoffs

ApproachProsCons
Simple DCEFast, easyMisses opportunities
Aggressive DCERemoves more codeMore complex
ADCE with interproceduralGlobal optimizationVery expensive

When NOT to Use This Skill

  • When code size is not a concern
  • For debug builds (keep code for debugging)
  • When side effects are unclear (volatile, I/O)

Limitations

  • May remove intentionally dead code (defensive programming)
  • Cannot remove code that might have side effects
  • Interprocedural DCE requires whole-program analysis

Assessment Criteria

A high-quality implementation should have:

CriterionWhat to Look For
SoundnessNever removes code that affects output
CompletenessRemoves all provably dead code
SpeedFast enough for production use
IterationReaches fixpoint

Quality Indicators

✅ Good: Removes all dead code, preserves semantics, fast ⚠️ Warning: Removes some but not all dead code ❌ Bad: Removes code that affects program output

Research Tools & Artifacts

Real-world DCE implementations:

ToolWhy It Matters
LLVM DCE passProduction DCE in LLVM
GCC DCEGCC's dead code elimination
Soot DCEJava bytecode DCE
GraalVM DCETruffle-based DCE

Key Optimizations

  • ADCE (Aggressive DCE): More aggressive than standard
  • LICM with DCE: Loop-invariant code motion

Research Frontiers

Current DCE research:

DirectionKey PapersChallenge
Interprocedural DCE"Whole-program DCE"Cross-module analysis
Type-based DCE"Type-driven DCE"Type information
Dynamically dead"Dynamic Dead Code"Runtime dead code

Hot Topics

  1. DCE for microservices: Removing unused endpoints
  2. Web bundle optimization: Tree-shaking in bundlers

Implementation Pitfalls

Common DCE bugs:

PitfallReal ExamplePrevention
Side effectsRemoving print statementsTrack I/O precisely
VolatileRemoving volatile readsHandle volatile
FinalizersRemoving finalize()Don't remove finalizers
Self-modifyingRemoving JIT codeHandle dynamic code

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free