[Arith] Make Analyzer a tvm-ffi Object - #19675
Merged
Merged
Conversation
tlopex
force-pushed
the
analyzer-ffi-object
branch
from
June 5, 2026 08:52
e155636 to
55f38ab
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request refactors the arithmetic Analyzer in TVM to be a first-class FFI object. The stateful Analyzer class is renamed to AnalyzerObj (inheriting from ffi::Object), and Analyzer is redefined as a lightweight, reference-counted handle (ffi::ObjectRef) wrapping it. This allows Analyzer instances to be passed across the TVM FFI boundary (e.g., between Python and C++) and shared, preserving accumulated bindings and constraints. Numerous function signatures and call sites across the codebase have been updated to accept AnalyzerObj* instead of Analyzer*, and member accesses on Analyzer now use the arrow operator (->). Additionally, Python bindings and index mapping utilities have been updated to support passing an external Analyzer instance, and corresponding tests have been added. No reviewer comments were provided, so there is no additional feedback to address.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
tqchen
previously requested changes
Jun 5, 2026
tlopex
force-pushed
the
analyzer-ffi-object
branch
5 times, most recently
from
June 5, 2026 20:15
9697f79 to
ef6cabb
Compare
tlopex
force-pushed
the
analyzer-ffi-object
branch
3 times, most recently
from
June 7, 2026 03:10
986240b to
2eed01e
Compare
tlopex
force-pushed
the
analyzer-ffi-object
branch
from
June 7, 2026 03:24
2eed01e to
66191ea
Compare
Ubospica
force-pushed
the
analyzer-ffi-object
branch
from
June 8, 2026 02:22
8f84480 to
f07de85
Compare
tlopex
force-pushed
the
analyzer-ffi-object
branch
from
June 8, 2026 03:57
f07de85 to
3478fd9
Compare
…d tests Now that arith::Analyzer is a tvm-ffi object, expose more of its stateful surface to Python and let callers share a single analyzer across FFI calls. - Add Python bindings for additional Analyzer methods. - Accept optional analyzers in iter-map, int-set, and IndexMap helper APIs. - Keep IndexMap inverse temporary bindings out of caller-provided analyzers. - Add targeted tests for optional analyzer reuse and state isolation.
tlopex
force-pushed
the
analyzer-ffi-object
branch
from
June 8, 2026 04:01
3478fd9 to
23af9ce
Compare
Ubospica
force-pushed
the
analyzer-ffi-object
branch
2 times, most recently
from
June 8, 2026 04:58
b58d406 to
55a6199
Compare
Ubospica
force-pushed
the
analyzer-ffi-object
branch
from
June 8, 2026 05:19
55a6199 to
23af9ce
Compare
Ubospica
approved these changes
Jun 8, 2026
guan404ming
approved these changes
Jun 8, 2026
guan404ming
left a comment
guan404ming
left a comment
Member
There was a problem hiding this comment.
Great work, thanks @tlopex
tlopex
added a commit
to tlopex/tvm
that referenced
this pull request
Jun 18, 2026
…t Analyzer& After apache#19675 made arith::Analyzer an FFI object, IRMutatorWithAnalyzer and its subclasses took AnalyzerObj*, forcing every instantiation site to pass analyzer.get(). Migrate the IRMutatorWithAnalyzer family to accept the Analyzer handle directly. Changes: - IRMutatorWithAnalyzer gains a `const Analyzer&` constructor overload. The existing `AnalyzerObj*` overload is kept on purpose: RewriteSimplifier::Impl is constructed from the AnalyzerObj's own `this` mid-construction, where no Analyzer handle exists yet and GetRef on a half-built, self-owned object would be unsafe / form an ownership cycle. - The directly-instantiated subclass constructors switch AnalyzerObj* -> const Analyzer&, dropping analyzer.get() at their call sites. - For the factory-style subclasses (NoOpRemover, StmtSimplifier) the construction happens inside their static Apply()/free-function entry points, so those internal (src/, non-FFI, non-public) signatures move to const Analyzer& as well -- StmtSimplify(), RemoveNoOp() and BlockBufferAccessSimplifier::Simplify() -- removing analyzer.get() at the remaining call sites. Deliberately left as AnalyzerObj*: - The per-sub-analyzer `AnalyzerObj* parent` constructors (ConstIntBound, ModularSet, IntSet, Canonical, RewriteSimplifier): AnalyzerObj owns them by value, so a strong back-reference would be a cycle. - VTInjector: it is built from the inherited raw analyzer_ member and never wrote analyzer.get() to begin with. The field stays `AnalyzerObj* analyzer_` (borrowed), so there is no extra refcount and no ownership cycle. Because AnalyzerObj is _type_mutable, a const Analyzer& still exposes a non-const operator->, so subclass bodies (analyzer_->Bind(...)) are unchanged. No Python / FFI / public-header surface changes; runtime behavior is identical.
tlopex
added a commit
to tlopex/tvm
that referenced
this pull request
Jun 18, 2026
After apache#19675 made arith::Analyzer an FFI object, IRMutatorWithAnalyzer and its subclasses took AnalyzerObj*, forcing every instantiation site to pass analyzer.get(). Migrate the IRMutatorWithAnalyzer family to accept the Analyzer handle directly. Changes: - IRMutatorWithAnalyzer gains a `const Analyzer&` constructor overload. The existing `AnalyzerObj*` overload is kept on purpose: RewriteSimplifier::Impl is constructed from the AnalyzerObj's own `this` mid-construction, where no Analyzer handle exists yet and GetRef on a half-built, self-owned object would be unsafe / form an ownership cycle. - The directly-instantiated subclass constructors switch AnalyzerObj* -> const Analyzer&, dropping analyzer.get() at their call sites. - For the factory-style subclasses (NoOpRemover, StmtSimplifier) the construction happens inside their static Apply()/free-function entry points, so those internal (src/, non-FFI, non-public) signatures move to const Analyzer& as well -- StmtSimplify(), RemoveNoOp() and BlockBufferAccessSimplifier::Simplify() -- removing analyzer.get() at the remaining call sites. Deliberately left as AnalyzerObj*: - The per-sub-analyzer `AnalyzerObj* parent` constructors (ConstIntBound, ModularSet, IntSet, Canonical, RewriteSimplifier): AnalyzerObj owns them by value, so a strong back-reference would be a cycle. - VTInjector: it is built from the inherited raw analyzer_ member and never wrote analyzer.get() to begin with. The field stays `AnalyzerObj* analyzer_` (borrowed), so there is no extra refcount and no ownership cycle. Because AnalyzerObj is _type_mutable, a const Analyzer& still exposes a non-const operator->, so subclass bodies (analyzer_->Bind(...)) are unchanged. No Python / FFI / public-header surface changes; runtime behavior is identical.
tlopex
added a commit
to tlopex/tvm
that referenced
this pull request
Jun 18, 2026
After apache#19675 made arith::Analyzer an FFI object, IRMutatorWithAnalyzer and its subclasses took AnalyzerObj*, forcing every instantiation site to pass analyzer.get(). Migrate the IRMutatorWithAnalyzer family to accept the Analyzer handle directly. Changes: - IRMutatorWithAnalyzer gains a `const Analyzer&` constructor overload. The existing `AnalyzerObj*` overload is kept on purpose: RewriteSimplifier::Impl is constructed from the AnalyzerObj's own `this` mid-construction, where no Analyzer handle exists yet and GetRef on a half-built, self-owned object would be unsafe / form an ownership cycle. - The directly-instantiated subclass constructors switch AnalyzerObj* -> const Analyzer&, dropping analyzer.get() at their call sites. - For the factory-style subclasses (NoOpRemover, StmtSimplifier) the construction happens inside their static Apply()/free-function entry points, so those internal (src/, non-FFI, non-public) signatures move to const Analyzer& as well -- StmtSimplify(), RemoveNoOp() and BlockBufferAccessSimplifier::Simplify() -- removing analyzer.get() at the remaining call sites. Deliberately left as AnalyzerObj*: - The per-sub-analyzer `AnalyzerObj* parent` constructors (ConstIntBound, ModularSet, IntSet, Canonical, RewriteSimplifier): AnalyzerObj owns them by value, so a strong back-reference would be a cycle. - VTInjector: it is built from the inherited raw analyzer_ member and never wrote analyzer.get() to begin with. The field stays `AnalyzerObj* analyzer_` (borrowed), so there is no extra refcount and no ownership cycle. Because AnalyzerObj is _type_mutable, a const Analyzer& still exposes a non-const operator->, so subclass bodies (analyzer_->Bind(...)) are unchanged. No Python / FFI / public-header surface changes; runtime behavior is identical.
tlopex
added a commit
that referenced
this pull request
Jun 18, 2026
This pr is the follow-up pr to #19675. IRMutatorWithAnalyzer and its subclasses took AnalyzerObj*, so callers had to pass analyzer.get(). This adds a const Analyzer& constructor and migrates the family (and their Apply() / free-function entry points) to take the handle directly, dropping .get() at the call sites. The original AnalyzerObj* overload is kept because RewriteSimplifier::Impl is constructed from the AnalyzerObj's own this during the analyzer's construction, where no Analyzer handle exists yet. And the same dual-overload pattern already used by arith::ConstraintContext.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR makes
arith::Analyzera first-class tvm-ffi object.The implementation splits the previous concrete
Analyzerclass into:AnalyzerObj, the mutable object node that owns analyzer state, sub-analyzers, caches, and bindingsAnalyzer, a reference-countedObjectRefhandle that can be passed across the tvm-ffi boundaryThis allows Python and C++ to share the same analyzer instance, so bindings, constraints, and cached facts can persist across FFI calls.
Public APIs that accept an analyzer now use
const arith::Analyzer&, while internal helper APIs that only borrow the object continue to useAnalyzerObj*.