I am a PhD student in Computer Science at George Washington University, advised by Prof. Jie Zhou.
My research is in programming languages and program analysis, particularly pointer and alias analysis for Rust and LLVM.
I study the runtime behavior of unsafe Rust, develop pointer-analysis infrastructure in SVF and rustc, and investigate how LLVM uses alias information during optimization.
I am seeking a Summer 2027 research internship in programming languages, program analysis, or compilers. Please get in touch if you know of a relevant opportunity or would be willing to make a referral.
Source-level counts of unsafe code do not explain what executes or which memory objects it accesses. I developed a compiler-based dynamic analysis framework that carries source-level unsafety into LLVM IR and instruments execution and heap accesses to investigate these behaviors. Our study of 100 popular crates containing unsafe code shows how safe APIs invoke unsafe code and how incorporated standard-library code adds substantial unsafe execution. Using these measurements, we curated an 18-crate benchmark for evaluating unsafe-Rust defenses, selecting workloads by unsafe execution, heap usage, and code coverage across diverse program types and unsafe patterns. The measurements characterize behavior under the evaluated workloads; they do not identify vulnerabilities.
I investigate how Rust-generated LLVM IR loses the information needed to identify heap objects accessed by unsafe code. Using SVF's Andersen analysis integrated into rustc, I developed demand-driven tracing through integer–pointer casts and intervening stores to recover heap targets missed in hashbrown's type-punned pointer representation.
Evaluation against runtime heap-access observations distinguishes missed targets from predictions not exercised by the inputs. Recovering targets and narrowing candidate sets are separate problems: type-erased, byte-offset accesses can still produce large points-to sets even when observed targets are recovered.
Connecting the recovered points-to information to LLVM's alias-analysis framework through ExternalAA is ongoing.
Evaluation scope and limitations
The August 3, 2026 experimental-branch run covered 944 executed static memory-access sites under fat LTO with one codegen unit: 350 confirmed matches, 2 misses, 7 unconfirmed predictions, and 585 negative sites. Recall was 350/(350+2) = 99.43%; the conservative precision estimate was 350/(350+7) = 98.04%, treating all unconfirmed predictions as false positives. These workload-dependent heap-target measurements do not establish memory safety, analysis soundness, or points-to set precision, and are not a measurement of every current branch.
Characterizing unresolved queries in LLVM alias analysis
2026–present
I study why LLVM's alias analyses leave queries unresolved and which missing facts affect optimization. I instrumented AAResults and BasicAA to attribute query outcomes and give-up reasons, then combined provider ablations with a deliberately unsound NoAlias intervention to study changes in optimized IR.
In the selected Rust corpus, queries whose pointers trace to the same object had a larger load-count effect than the class targeting distinct objects reached through loaded pointers; the ordering reversed in C/C++. This is a contrast between the measured corpora, not an intrinsic difference between the languages. The study covers 346 Rust, 189 C/C++, and 614 SPEC CPU2017 compilation units.
Separate executable alias-information ablations test the limits of static metrics: neither query counts nor load-count changes alone establish runtime benefit. Manuscript in preparation.
Evaluation scope and limitations
The forced-NoAlias experiment produced median load-count reductions of 15.59% for Rust and 6.79% for C/C++, measured per compilation unit over functions surviving in both baseline and treated IR. Units were selected to contain at least 500 post-O3 loads. Because the intervention can return incorrect alias answers and the surviving functions are selected after treatment, these figures are neither achievable optimization gains nor unbiased general upper bounds. The treated binaries are not executed. The separate parameter-attribute removal experiment measures runtime on executable binaries.
Open source
Contributions to the upstream Static Value-Flow Analysis framework.All authored PRs
Aggregate and vector pointer fields
Modeled demanded pointer fields in local aggregates and fixed vectors, preserving Phi predecessors and Select conditions for value-flow consumers. Repeated extracts share field definitions instead of falling back to a black hole.
Made AndersenWaveDiff process newly added points-to targets for existing load/store constraints, while replaying the full set for constraints introduced by SCC merges. Exact points-to outputs matched the baseline on libcurl, tmux, and bash.
Added getMayAliasesBatch with bounded, per-call answer reuse for equal points-to sets. Fixed 128-query samples on libcurl, tmux, and bash ran 14.3–22.7× faster than scalar queries; these measurements exclude analysis solving.
Extending the shared pointer-field model across eligible direct aggregate-returning calls, using per-callsite slots and caller snapshots. External and indirect calls retain the existing fallback.
Designed getMayAliases and its Andersen implementation using reverse points-to sets and SCC membership. Validated the returned alias sets against exhaustive pairwise queries; the upstream suite passed all 2,575 registered tests.
Ported SVF to LLVM 21 and restored test-suite parity, recovering field constraints for opaque-pointer array accesses and byte-layout memcpy/memmove operations.
Fixed negative and out-of-range struct-index handling in GEP offset computation, preserving conservative points-to relationships for back-offsetting pointers used by Rust's hashbrown.
Replaced repeated candidate checks with direct reverse-set queries and dense-bitset accumulation. Measured 4.78–43.64× query speedups across four modules on sampled LLVM values completed by both versions. A same-process exhaustive check found zero mismatches in 8.7 million comparisons; this is query time, not solver or end-to-end compilation time.
