Module analysis

[Y-Nak]

Please start reviewing after #96 is merged.

NOTE: A.I. generates the comment below, but I'm not entirely sure if this comment is helpful or not.

Pull Request: Module Analysis Framework Enhancement

Summary

This PR introduces a framework for analyzing the structure and properties of a Module in the Sonatina IR. The additions provide functionality to assess the module's dependency flow, call graph, and strongly connected components (SCCs), enabling insights into the recursive and external dependencies of functions.

Key Features

1. Module Analysis Framework

• Module Analysis API:

  • Adds the analyze_module function to perform analysis of a module, returning a ModuleInfo object.
  • ModuleInfo encapsulates:
    • Strongly connected components (CallGraphSccs).
    • Call graph structure (CallGraph).
    • Per-function information (FuncInfo).
    • Dependency flow of the module (DependencyFlow).

• DependencyFlow Enumeration:

  • Represents four states of call dependency: OutgoingOnly, IncomingOnly, Bidirectional, and Closed.
  • Implements a lattice-based join operation for combining dependency states and a remove_flow function for refining flow states.

2. Call Graph Analysis

• Call Graph Construction:

  • Extracts and organizes function call relationships into a CallGraph.
  • Supports traversal, leaf function detection, and callee inspection.

• SCC Analysis:

  • Implements Tarjan's algorithm via the SccBuilder to identify SCCs in the call graph.
  • Annotates SCCs with cyclicity and member functions.

3. Function Information

• Determines per-function properties:
  • Recursiveness: Detects whether a function is part of a recursive call chain.
  • Leaf Functionality: Identifies functions without outgoing calls.
  • Dependency Flow: Categorizes function dependencies with respect to external entities.

4. DependencyFlow analysis

• Aggregates data to determine the global DependencyFlow of the module.
• Utilizes the condensation DAG of the call graph to analyze all functions.

[sbillig]

It would be nice to support analyzing a known-to-be-complete program, composed of linked modules (but that can of course come later).

Can you remind me what is_leaf is useful for? It seems that any function that's known to not be involved in a recursive loop can have a stable frame region; is there something special we can do with leaf functions that I'm forgetting? Two separate leaves could have overlapping stable regions, but that's a special case of disjoint branches.

[sbillig]

The FuncInfo for externally-defined %fx is weird; local functions call it, so its flow is known to be Incoming, and we should assume that it may be Bidirectional. We also can't say that it's a leaf.

[Y-Nak]

Yeah, this is bad. I initially thought that we should remove the external function from the result, but also hesitated to do that because it breaks the consistency between the result and FuncStore or other modules, which always manage the mapping from each FuncRef to some information.

I'm inclined to remove the external function info from the ModuleInfo now because the information won't be used anywhere(and actually, if it's used, it just gives wrong information or the most conservative information). What's your thought?

[sbillig]

Yeah, I think it's fine to remove it and for the backend to assume the most conservative for calls to mysterious external functions.

[Y-Nak]

It would be nice to support analyzing a known-to-be-complete program, composed of linked modules (but that can of course come later).

What is additional analysis in your mind when the entire program is provided? I assumed that by using module_linker to combine multiple modules before analysis, it'd be possible to obtain more fine-grained and comprehensive analysis results(and for the EVM backend, the great difference in the quality of the analysis would depend on whether the module is Bidirectional or not).

Can you remind me what is_leaf is useful for?

It depends on the backend. It won't be so useful for EVM codegen(but, we might need the information in addition to the DependencyFlow/Sccs for inlining). But for the "normal" ISA, it's useful for codgen as well.

[sbillig]

It would be nice to support analyzing a known-to-be-complete program, composed of linked modules (but that can of course come later).

What is additional analysis in your mind when the entire program is provided? I assumed that by using module_linker to combine multiple modules before analysis, it'd be possible to obtain more fine-grained and comprehensive analysis results(and for the EVM backend, the great difference in the quality of the analysis would depend on whether the module is Bidirectional or not).

Just more comprehensive information; no need to be overly conservative when calling external functions, for example. In practice, fe or solc can just generate the whole program in a single sonatina module and this 'multi-module whole-program analysis' isn't needed for now.

[Y-Nak]

I see. I probably understand what you mean. So, you mean that it'd be nicer if the analysis phase could take an arbitrary number of Modules or integrate multiple ModuleInfo to refine information accordingly, right?
By assuming my understanding is correct, I changed the external function information to the most conservative form
instead of removing it so that we can easily perform the improvement(i.e., after such refinement, the external function also could have more useful information).