d5af6b1d48
Added paper-g-ai-assisted-compiler folder documenting: - Week-long LLVM backend development with AI assistance - Key insights from PHI/SSA struggles to Resolver API solution - Development log capturing the chaotic reality - Abstract in both English and Japanese Key quote: 'I don't remember anymore' - capturing the authentic experience of intensive AI-assisted development where the process itself becomes the research data. This represents potentially the first fully documented case of building a compiler backend primarily through AI assistance.
1.3 KiB
1.3 KiB
Resolver API (Minimal i64 Prototype)
Goals
- Centralize "ValueId → current-block value" resolution.
- Guarantee dominance by localizing values at the start of the block (before non-PHI).
- De-duplicate per (block, value) to avoid redundant PHIs/casts.
Design
Resolverkeeps small per-function caches keyed by(BasicBlockId, ValueId).resolve_i64(...)returns ani64-typedIntValue, inserting PHI and casts as needed using sealed snapshots.resolve_ptr(...)returns ani8*PointerValue, PHI at BB start; int handles are bridged viainttoptr.resolve_f64(...)returns anf64FloatValue, PHI at BB start; ints bridged viasitofp.- Internally uses
flow::localize_to_i64(...)for the i64 path; pointer/float are localized directly.
Usage (planned wiring)
- Create
let mut resolver = instructions::Resolver::new();at function lowering start. - Replace all integer value fetches in lowerers with
resolver.resolve_i64(...). - Keep builder insertion discipline via
BuilderCursor.
Next
- Migrate remaining
localize_to_i64call sites to the resolver. - Enforce vmap direct access ban in lowerers (Resolver-only for reads).
Acceptance tie-in
- Combined with LoopForm: dispatch-only PHI + resolver-based value access → dominance violations drop to zero (A2.5).