Files

tomoaki 757193891f feat(llvm/phi): Phase 277 P1 - fail-fast validation for PHI strict mode

## Summary
Implemented fail-fast validation for PHI ordering and value resolution in strict mode.

## Changes

### P1-1: Strict mode for "PHI after terminator"
- File: `src/llvm_py/phi_wiring/wiring.py::ensure_phi`
- Behavior: `NYASH_LLVM_PHI_STRICT=1` → RuntimeError if PHI created after terminator
- Default: Warning only (no regression)

### P1-2: Strict mode for "fallback 0"
- File: `src/llvm_py/phi_wiring/wiring.py::wire_incomings`
- Behavior: Strict mode forbids silent fallback to 0 (2 locations)
  - Location 1: Unresolvable incoming value
  - Location 2: Type coercion failure
- Error messages point to next debug file: `llvm_builder.py::_value_at_end_i64`

### P1-3: Connect verify_phi_ordering() to execution path
- File: `src/llvm_py/builders/function_lower.py`
- Behavior: Verify PHI ordering after all instructions emitted
- Debug mode: Shows "✅ All N blocks have correct PHI ordering"
- Strict mode: Raises RuntimeError with block list if violations found

## Testing
✅ Test 1: strict=OFF - passes without errors
✅ Test 2: strict=ON - passes without errors (no violations in test fixtures)
✅ Test 3: debug mode - verify_phi_ordering() connected and running

## Scope
- LLVM harness (Python) changes only
- No new environment variables (uses existing 3 from Phase 277 P2)
- No JoinIR/Rust changes (root fix is Phase 279)
- Default behavior unchanged (strict mode opt-in)

## Next Steps
- Phase 278: Remove deprecated env var support
- Phase 279: Root fix - unify "2本のコンパイラ" pipelines

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

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2025-12-22 14:48:37 +09:00

3.0 KiB

Raw Blame History

Phase 279 P0: Unify type propagation pipeline (SSOT)

Status: planned / implementation

Problem:

Type propagation and PHI type resolution are executed in multiple routes with different orderings.
This creates “double bugs”: the same fixture can pass in one route and fail in another, even when the frontend and MIR are identical.

Goal:

Define a single TypePropagationPipeline (SSOT) with a fixed order, and make all routes call it.

Constraints:

No new environment variables.
No by-name hardcode dispatch.
Fail-fast on invariants (no silent fallback).

1) Define the SSOT pipeline (single entry)

Create one entry function (name is flexible, keep it unambiguous):

run_type_propagation_pipeline(module: &mut MirModule, mode: ...) -> Result<(), String>

Fixed order (SSOT):

Copy type propagation
BinOp type re-propagation
PHI type resolution
Minimal follow-ups required for downstream typing (Compare / TypeOp / etc.), only if already needed by current backends

Hard rule:

No route may run PHI type resolution before BinOp re-propagation.

Rationale:

PHI type inference depends on stabilized incoming value types.

2) Route integration (remove local ordering)

Make all relevant routes call the SSOT entry and remove/disable any local ordering logic.

Known routes to check (examples; confirm in code):

Builder lifecycle path (emits MIR directly)
JoinIR → MIR bridge path
Any “analysis/json emit” path that downstream LLVM harness relies on for value_types

Acceptance:

Each route calls the same SSOT entry.
There is no remaining “partial pipeline” that can reorder steps.

3) Fail-fast order guard (prevent regressions)

Add an invariant checker that makes order drift obvious:

If PHI type resolution is invoked while BinOp re-propagation has not run, return Err(...).

This is not a feature toggle. It is a structural guard.

4) Backends: define the contract for `value_types`

Document (in code/doc) what the downstream expects:

A ValueId that is f64 must be consistently typed as f64 across:
- MIR instruction dst_type
- propagated/inferred value_types
- PHI dst_type
“i64 handle” vs “unboxed f64” must be consistent for the LLVM harness.

Avoid “best-effort” inference at the harness layer. If the type is unknown, fail-fast where the SSOT contract is violated.

5) Minimal acceptance tests

Minimum:

A representative fixture that exercises:
- Copy chain
- BinOp promotion (e.g. Int+Float)
- PHI over that promoted value and is executed via all relevant routes.
The MIR JSON value_types is consistent across routes.

Suggested validation commands (keep local, do not add CI jobs):

cargo build --release
relevant smoke(s): tools/smokes/v2/run.sh --profile quick

6) Completion criteria

No route-specific ordering logic remains.
Order guard prevents PHI-before-BinOp execution.
A reproduction fixture cannot diverge across routes due to type propagation ordering.
Documentation points to this phase as the SSOT for “pipeline unification”.

3.0 KiB Raw Blame History