You are analyzing the React Compiler's SSA conversion and type inference passes. This is research only -- do NOT edit any files.
The goal is to produce a structured analysis document that will help us adapt these concepts for CloudLang, an OCaml compiler that decomposes TypeScript closures into Cloudflare Workers.
Files to read and analyze (all under /home/jm/data/ai/cloudlang-trees/react/react/compiler/packages/babel-plugin-react-compiler/src/):
SSA/EnterSSA.ts- SSA conversionSSA/EliminateRedundantPhi.ts- Phi node simplificationSSA/RewriteInstructionKindsBasedOnReassignment.ts- Post-SSA instruction kind fixupTypeInference/InferTypes.ts- Type inference passHIR/HIR.ts- Reference for types (especially Phi, Place, Identifier, MutableRange)HIR/Types.ts- Type system definitionsHIR/Environment.ts- Environment/config (for understanding type provider setup)
Also read CloudLang's current scope analysis for comparison:
/home/jm/data/ai/cloudlang-trees/react/lib/scope.ml/home/jm/data/ai/cloudlang-trees/react/lib/scope.mli
Produce documentation for each pass using this template:
# Pass Name
## File
## Purpose
## Input Invariants
## Output Guarantees
## Algorithm (detailed, step-by-step)
## Key Data Structures
## Edge Cases
## Mapping to CloudLang
- What we'd adapt and how
- What we'd skip and why
- OCaml type sketches for the adapted versions
## Example (before/after)
Specific questions to answer:
SSA Construction (EnterSSA.ts):
- What algorithm is used? (Cytron et al? Braun et al? Something simpler?)
- How are phi nodes placed? What's the phi insertion strategy?
- How does it handle different scopes (block scope, function scope, catch)?
- How are
IdentifierIdvalues assigned? What's the numbering scheme? - What happens to the
namefield on identifiers after SSA? (renamed? preserved?) - How does it interact with the existing HIR structure (blocks, terminals)?
Phi Node Elimination (EliminateRedundantPhi.ts):
- What makes a phi node "redundant"?
- What's the simplification algorithm?
- What's the effect on the rest of the HIR?
Instruction Kind Rewriting (RewriteInstructionKindsBasedOnReassignment.ts):
- Why is this needed post-SSA?
- What instruction kinds change and why?
- What's the relationship between
const/let/reassignand SSA?
Type Inference (InferTypes.ts):
- What type lattice is used?
- Is this a standard forward dataflow analysis?
- How does it handle phi nodes?
- What types are inferred? (Primitive, Function, Object, etc.)
- How do "shapes" (from ObjectShape.ts) feed into type inference?
- How are built-in types (Array, Map, Set, etc.) represented?
- What role do types play in subsequent passes (especially mutation inference)?
For CloudLang specifically:
- Our scope.ml already tracks free variables, mutable state, and called functions. How would SSA improve our analysis? What new capabilities would it unlock?
- We care about: which closures capture which state, whether that state is mutated, and data flow between closures. How does SSA + type inference serve these goals?
- What's the minimal SSA we could implement to get mutation/aliasing analysis working?
Return your complete analysis as a single structured markdown document. Be very thorough on the SSA algorithm details -- we need to understand it well enough to implement in OCaml.