-
Notifications
You must be signed in to change notification settings - Fork 6
Feature request: support Protocol-based ir.Data interface #625
Copy link
Copy link
Open
Labels
C-feature-requestCategory: This is a feature request, i.e: not implemented / a PRCategory: This is a feature request, i.e: not implemented / a PRarea: IRArea: issues related to the IR module.Area: issues related to the IR module.category: enhancementCategory: this is an enhancement of an existing feature.Category: this is an enhancement of an existing feature.category: featureCategory: new feature or feature request.Category: new feature or feature request.
Metadata
Metadata
Assignees
Labels
C-feature-requestCategory: This is a feature request, i.e: not implemented / a PRCategory: This is a feature request, i.e: not implemented / a PRarea: IRArea: issues related to the IR module.Area: issues related to the IR module.category: enhancementCategory: this is an enhancement of an existing feature.Category: this is an enhancement of an existing feature.category: featureCategory: new feature or feature request.Category: new feature or feature request.
Summary
Allow compiler attribute types to satisfy the
ir.Datainterface via structural typing (PythonProtocol) instead of requiring inheritance from a concrete base class.Motivation
In bloqade-lanes, we have Rust-backed types (via PyO3) that carry device-level data (addresses, lane descriptors, etc.) used as IR attributes. These types need to satisfy Kirin's
ir.Datainterface to participate in the compiler pipeline.Since PyO3
#[pyclass]types cannot inherit from Python-defined base classes (a known PyO3 limitation), we currently maintain a separate layer of pure-Python wrapper classes whose sole purpose is to:ir.Data/Encoderbase classself._innerThis creates a three-layer type stack (Rust → PyO3 binding → Python wrapper) that adds code complexity, maintenance burden, and conversion overhead at every IR boundary.
If
ir.Datawere defined as aProtocol(PEP 544), any type that implements the required methods would automatically satisfy the interface — no inheritance needed. Rust-backed types could participate directly in the IR without wrappers.Proposed change
Define the
ir.Datainterface as atyping.Protocol(or provide a Protocol alternative alongside the current base class for backward compatibility):This would allow any type — including PyO3 extension types — to satisfy the interface through structural subtyping rather than nominal inheritance.
Backward compatibility
A Protocol-based approach could coexist with the current base class:
ir.Datawould continue to workisinstance()would work if the Protocol is@runtime_checkableContext
#[pyclass]cannot inherit from Python classesir.Datainterface