Repository navigation
docs(rewrite): design the M3 analysis manager - #857
alexcgatea wants to merge 2 commits into
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| pub trait Analysis<S>: AnalysisKey { | ||
| /// What the caller chooses when registering the analysis, such as the | ||
| /// roots to analyze from and their arguments. | ||
| type Input: 'static; |
There was a problem hiding this comment.
'static lifetime looks a bit strange to me, why we are requiring 'static?
Roger-luo
left a comment
Roger-luo
left a comment
There was a problem hiding this comment.
my main concern is whether Manager objects actually duplicates with a potential "database" storage in a query-based architecture
|
|
||
| ## Goals | ||
|
|
||
| 1. A rule can say which analyses it needs, and the manager computes them |
There was a problem hiding this comment.
I think this is where a query could enters, a rule/pass delcaration could have a corresponding query to some information, which declares its dependency. You can think a rewrite rule is a pure function f(analysis data, IR) -> IR, where analysis data also comes from IR, which will allow you to compute the dependency of
IR changes -> rewrite rule
| ^
|---> anaysis change |
| ### Example | ||
|
|
||
| ```rust | ||
| let mut analyses = AnalysisManager::new(); |
There was a problem hiding this comment.
I think the MLIR's manager object is essentially salsa's storage, I'm ok doing a first pass based on MLIR, but eventually we need to think about how does salsa play with this infrastructure instead of just reinventing MLIR in rust...
There was a problem hiding this comment.
| As in MLIR, where a pattern receives analysis results in its constructor, a | ||
| native rule receives them in its **recipe**: the function the rule set calls | ||
| to build a fresh rule for each sweep (or each block). The rule keeps the | ||
| `Rc`s it needs. A rule also declares what it requires: |
There was a problem hiding this comment.
do we actually need Rc? and should it be an Arc?
Draft: design doc only, no code yet.
What
docs/design/analysis-manager.mddesigns milestone M3 ofrewrite-engine.md: how rewrite passes get analysis results (constprop, demand), how those results are cached, and when they are dropped.Key decisions
AnalysisManagercomputes and caches;PassRunnerruns passes. The runner owns the pipeline and the manager, so no edit goes unseen. This follows MLIR's split between the analysis manager and the pass manager..requires::<A>()). A registry, as in LLVM's new pass manager, lets the runner compute those analyses before the pass.rewrite-engine.mdrequires. A pass with no edits keeps everything.Interpreter change, for review
The last section, "Interpreter changes (for review)", proposes that
analyzereturn an ownedAnalyzedinstead of wrapping the engine. Today the result borrows the pipeline, so the manager can't keep it across passes. With owned results, one result type serves every analysis, and the three per-engineAnalysisResultsimpls become one. @zhenrongliew, could you review this part in particular?