LLVM 22.x tile for building compilers, language runtimes, and out-of-tree tooling
88
83%
Does it follow best practices?
Impact
96%
1.23xAverage score across 5 eval scenarios
Passed
No known issues
A compiler research team at a university is building a custom static analysis toolkit on top of LLVM 22. They want to ship a standalone opt plugin that identifies and reports dead stores (stores to memory locations whose values are never subsequently loaded). Rather than patching LLVM itself, they want a loadable pass plugin distributed as a shared library that anyone with LLVM 22 installed can drop in and run with opt --load-pass-plugin.
The team has been burned before by out-of-tree projects that used the old LLVM pass infrastructure and broke every LLVM release. They want this new plugin built correctly from the start using the current pass infrastructure — structured so opt can find and register it, and with a lit test that validates basic behavior.
Produce the following files that together form the complete pass plugin project:
CMakeLists.txt — root CMake file for the projectDeadStoreReporter.h — pass class declarationDeadStoreReporter.cpp — pass implementation (the pass should at minimum iterate over a function's instructions and report stores; the exact analysis logic is up to you)test/dead-store-reporter.ll — a lit test file for the plugin using FileCheckThe pass should be named dead-store-reporter in the opt pipeline (i.e., usable via -passes=dead-store-reporter).
Keep the implementation focused — the grader will check the structure and API choices, not the sophistication of the analysis.
docs
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
add-alias-analysis
add-attributes-metadata
add-calling-convention
add-debug-info
add-exception-handling
add-gc-statepoints
add-intrinsic
add-lto
add-sanitizer
add-vectorization-hint
frontend-to-ir
jit-setup
lit-filecheck
lower-struct-types
new-target
out-of-tree-setup
tessl-llvm
version-sync