(refactor): moving unsafe panic optimization into new dataflow format

[eytan-starkware]

Summary

Implement a new DataflowBackAnalysis adapter that bridges between the new DataflowAnalyzer trait and the legacy Analyzer trait for backward analysis. This enables a cleaner API for dataflow analysis while maintaining backward compatibility. The PR also refactors the early_unsafe_panic optimization to use this new adapter, improving code organization and clarity.

---

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

---

Why is this change needed?

The existing analysis framework required implementing the legacy Analyzer trait directly, which had a less intuitive API for dataflow analysis. This change introduces a more structured approach through the DataflowAnalyzer trait and an adapter pattern, making it easier to write new analyses while maintaining compatibility with existing code.

---

What was the behavior or documentation before?

Previously, all backward analyses had to implement the legacy Analyzer trait directly, which mixed traversal logic with analysis logic and required manual handling of statement processing.

---

What is the behavior or documentation after?

Now, analyses can implement the more focused DataflowAnalyzer trait, which separates traversal from analysis logic. The new DataflowBackAnalysis adapter handles the translation between the new and legacy interfaces. The early_unsafe_panic optimization has been refactored to use this new approach, resulting in cleaner, more maintainable code.

---

Additional context

This change is part of a larger effort to modernize the dataflow analysis framework in the compiler. It maintains backward compatibility while introducing a cleaner API for new analyses. The refactoring of early_unsafe_panic serves as an example of how to migrate existing analyses to the new framework.

[reviewable-StarkWare]

This change is 

[eytan-starkware]

• (refactor): moving unsafe panic optimization into new dataflow format #9534 : 2 dependent PRs (#9557 , #9558 ) 👈 (View in Graphite)
• (refactor): Updating analysis framework to be easier to use #9564 : 1 other dependent PR (#9584 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[orizi]

@orizi reviewed 2 files and all commit messages, and made 2 comments.
Reviewable status: 2 of 3 files reviewed, 2 unresolved discussions (waiting on @eytan-starkware, @ilyalesokhin-starkware, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 99 at r1 (raw file):

    pub reachability: Reachability<'db>,
    /// Locations where we need to insert unsafe_panic.
    pub fixes: Vec<(StatementLocation, LocationId<'db>)>,

holding multiple vectors sounds less efficient (in general) - any way to keep a way to do the original concept?

Code quote:

    pub fixes: Vec<(StatementLocation, LocationId<'db>)>,

---

crates/cairo-lang-lowering/src/analysis/mod.rs line 9 at r1 (raw file):

pub mod core;

// Re-export commonly used types at the module level for convenience.

remove at the original PR.

[eytan-starkware]

@eytan-starkware made 2 comments.
Reviewable status: 2 of 3 files reviewed, 2 unresolved discussions (waiting on @ilyalesokhin-starkware, @orizi, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/analysis/mod.rs line 9 at r1 (raw file):

Previously, orizi wrote…

remove at the original PR.

Done.

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 99 at r1 (raw file):

Previously, orizi wrote…

holding multiple vectors sounds less efficient (in general) - any way to keep a way to do the original concept?

You are correct it should have been in the context. Done

[orizi]

@orizi reviewed 3 files and all commit messages, made 1 comment, and resolved 2 discussions.
Reviewable status: 3 of 4 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware, @ilyalesokhin-starkware, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 96 at r2 (raw file):

}

/// Analysis info containing reachability state and accumulated fixes.

it no longer does - also, does it still need to exist?

Suggestion:

/// Analysis info containing reachability state.

[eytan-starkware]

@eytan-starkware made 1 comment.
Reviewable status: 3 of 4 files reviewed, 1 unresolved discussion (waiting on @ilyalesokhin-starkware, @orizi, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 96 at r2 (raw file):

Previously, orizi wrote…

it no longer does - also, does it still need to exist?

Actually unneeded, the info is just reachability

[graphite-app]

Merge activity

• Jan 27, 8:56 AM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.
• Jan 27, 2:09 PM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.
• Jan 28, 11:59 AM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.
• Jan 29, 10:59 AM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.

[orizi]

@orizi reviewed 1 file and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status: 3 of 4 files reviewed, 1 unresolved discussion (waiting on @eytan-starkware, @ilyalesokhin-starkware, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 104 at r3 (raw file):

    }

    fn merge(

why is the merge duplicated?

[eytan-starkware]

@eytan-starkware made 1 comment.
Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on @ilyalesokhin-starkware, @orizi, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 104 at r3 (raw file):

Previously, orizi wrote…

why is the merge duplicated?

Done.

[orizi]

@orizi reviewed 3 files and all commit messages, made 4 comments, and resolved 1 discussion.
Reviewable status: 3 of 4 files reviewed, 4 unresolved discussions (waiting on @eytan-starkware, @ilyalesokhin-starkware, and @TomerStarkware).

---

crates/cairo-lang-lowering/src/analysis/backward.rs line 198 at r5 (raw file):

            match_info.location(),
            transferred_infos.into_iter(),
        )

any reason not to keep as iterator?

Suggestion:

        let transferred_infos = match_info
            .arms()
            .iter()
            .zip(infos)
            .map(|(arm, info)| {
                let edge = Edge::MatchArm { arm, match_info };
                let transferred = self.analyzer.transfer_edge(&info, &edge);
                (arm.block_id, transferred)
            });
        self.analyzer.merge(
            statement_location,
            match_info.location(),
            transferred_infos,
        )

---

crates/cairo-lang-lowering/src/analysis/backward.rs line 206 at r5 (raw file):

        _vars: &'a [VarUsage<'db>],
    ) -> Self::Info {
        let block_end = &self.lowered.blocks[statement_location.0].end;

don't you need edges here as well?

---

crates/cairo-lang-lowering/src/analysis/backward.rs line 215 at r5 (raw file):

        _var: &VarUsage<'db>,
    ) -> Self::Info {
        let block_end = &self.lowered.blocks[statement_location.0].end;

don't you need edges here as well?

---

crates/cairo-lang-lowering/src/optimizations/early_unsafe_panic.rs line 100 at r5 (raw file):

    const DIRECTION: Direction = Direction::Backward;

    fn initial_info(&mut self, _block_id: BlockId, _block_end: &'a BlockEnd<'db>) -> Self::Info {

can you re-order the functions to make it easier to review there are no change?