Commit Graph

6 Commits

Author SHA1 Message Date
3f58f34592 feat(llvm): Phase 132-P0 - block_end_values tuple-key fix for cross-function isolation
## Problem
`block_end_values` used block ID only as key, causing collisions when
multiple functions share the same block IDs (e.g., bb0 in both
condition_fn and main).

## Root Cause
- condition_fn's bb0 → block_end_values[0]
- main's bb0 → block_end_values[0] (OVERWRITES!)
- PHI resolution gets wrong snapshot → dominance error

## Solution (Box-First principle)
Change key from `int` to `Tuple[str, int]` (func_name, block_id):

```python
# Before
block_end_values: Dict[int, Dict[int, ir.Value]]

# After
block_end_values: Dict[Tuple[str, int], Dict[int, ir.Value]]
```

## Files Modified (Python - 6 files)

1. `llvm_builder.py` - Type annotation update
2. `function_lower.py` - Pass func_name to lower_blocks
3. `block_lower.py` - Use tuple keys for snapshot save/load
4. `resolver.py` - Add func_name parameter to resolve_incoming
5. `wiring.py` - Thread func_name through PHI wiring
6. `phi_manager.py` - Debug traces

## Files Modified (Rust - cleanup)

- Removed deprecated `loop_to_join.rs` (297 lines deleted)
- Updated pattern lowerers for cleaner exit handling
- Added lifecycle management improvements

## Verification

-  Pattern 1: VM RC: 3, LLVM Result: 3 (no regression)
- ⚠️ Case C: Still has dominance error (separate root cause)
  - Needs additional scope fixes (phi_manager, resolver caches)

## Design Principles

- **Box-First**: Each function is an isolated Box with scoped state
- **SSOT**: (func_name, block_id) uniquely identifies block snapshots
- **Fail-Fast**: No cross-function state contamination

## Known Issues (Phase 132-P1)

Other function-local state needs same treatment:
- phi_manager.predeclared
- resolver caches (i64_cache, ptr_cache, etc.)
- builder._jump_only_blocks

## Documentation

- docs/development/current/main/investigations/phase132-p0-case-c-root-cause.md
- docs/development/current/main/investigations/phase132-p0-tuple-key-implementation.md

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-15 05:36:50 +09:00
af6f95cd4b Phase 33 NORM canon test: enforce normalized dev route for P1/P2/JP mini 2025-12-11 20:54:33 +09:00
d4597dacfa feat(joinir): Phase 245C - Function parameter capture + test fix
Extend CapturedEnv to include function parameters used in loop conditions,
enabling ExprLowerer to resolve variables like `s` in `loop(p < s.length())`.

Phase 245C changes:
- function_scope_capture.rs: Add collect_names_in_loop_parts() helper
- function_scope_capture.rs: Extend analyze_captured_vars_v2() with param capture logic
- function_scope_capture.rs: Add 4 new comprehensive tests

Test fix:
- expr_lowerer/ast_support.rs: Accept all MethodCall nodes for syntax support
  (validation happens during lowering in MethodCallLowerer)

Problem solved: "Variable not found: s" errors in loop conditions

Test results: 924/924 PASS (+13 from baseline 911)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 13:13:08 +09:00
2dfe363365 refactor(joinir): Phase 242-EX-A - Delete legacy Pattern3 lowerer
Remove hardcoded Pattern3 PoC implementation (loop_with_if_phi_minimal.rs)
and enhance if-sum mode to handle complex conditions like `i % 2 == 1`.

Key changes:
- condition_pattern.rs: Accept BinaryOp in comparison operands (+58 lines)
- loop_with_if_phi_if_sum.rs: Dynamic complex condition lowering (+147 lines)
- pattern3_with_if_phi.rs: Remove lower_pattern3_legacy() (-130 lines)
- loop_with_if_phi_minimal.rs: Delete entire file (-437 lines)
- loop_patterns/with_if_phi.rs: Update stub (-45 lines)
- mod.rs: Remove module reference (-4 lines)

Net reduction: -664 lines of hardcoded PoC code

Test results: 909/909 PASS (legacy mode completely removed)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 01:27:08 +09:00
f0536fa330 feat(joinir): Phase 222-2 ConditionPatternBox normalization implementation
Phase 222: If Condition Normalization - Part 2
Goal: Support '0 < i', 'i > j' patterns in addition to 'i > 0'

Changes:
1. condition_pattern.rs (+160 lines):
   - Added ConditionValue enum (Variable | Literal)
   - Added NormalizedCondition struct (left_var, op, right)
   - Added flip_compare_op() for operator reversal
   - Added binary_op_to_compare_op() converter
   - Added normalize_comparison() main normalization function
   - Extended analyze_condition_pattern() to accept 3 cases:
     * Phase 219: var CmpOp literal (e.g., i > 0)
     * Phase 222: literal CmpOp var (e.g., 0 < i) → normalized
     * Phase 222: var CmpOp var (e.g., i > j)
   - Added 9 unit tests (all passing)

2. loop_update_summary.rs (cleanup):
   - Commented out obsolete test_typical_index_names
   - Function is_typical_index_name() was removed in earlier phase

Test results:
- 7 normalization tests: PASS 
- 2 pattern analysis tests: PASS 

Next: Phase 222-3 - integrate normalization into is_if_sum_pattern()
Status: Ready for integration
2025-12-10 09:18:21 +09:00
d0d2a30c56 fix(joinir): Phase 219 regression fix - ConditionPatternBox
Introduced ConditionPatternBox to detect if condition complexity:
- Simple comparisons (var CmpOp literal): use AST-based if-sum lowerer
- Complex conditions (BinaryOp, etc.): fallback to legacy P3 lowerer

This fixes loop_if_phi.hako which was broken by Phase 219's
is_if_sum_pattern() changes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-10 03:54:17 +09:00