iree-org / iree-org/wave

Unify attribute conversion registry between FX → MLIR and MLIR → FX directions

Open
#872 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
59
Forks
32
PR merge metrics
No merged PRs in 30d

Description

Currently the attribute conversions between FX and MLIR are defined independently in two places:

- **FX → MLIR** (`water_emitter.py`): Attribute emission is spread across `_emit_common_attrs`, `_build_index_mapping_dict`, and op-specific handlers.
- **MLIR → FX** (`fx_emitter.py`): The `converters` dict in `_convert_supported_attrs` maps MLIR attribute names to conversion lambdas.

These two registries must be kept in sync manually. When support for a new attribute is added in one direction, it's easy to forget the other.

**Proposed approach:**

Create a single attribute registry (e.g. extending the existing `AttrNames` enum or a parallel structure) that pairs each attribute with its FX→MLIR serializer and MLIR→FX deserializer. Both `water_emitter.py` and `fx_emitter.py` would consume this registry, ensuring that adding a new attribute in one direction automatically surfaces a gap in the other.

This will require some design thought since the two directions have different signatures (the emitter needs access to the IR builder context, the converter needs the op for index resolution), but even a lightweight registry that just enforces "every attribute has both directions defined" would catch omissions at import time.

Contributor guide

Open the contributing guide

Research direction

Start by comparing attribute handling in water_emitter.py, including _emit_common_attrs, _build_index_mapping_dict, and op-specific handlers, with the converters mapping in fx_emitter.py's _convert_supported_attrs. Design a shared registry that accounts for both directions, then verify that every registered attribute has both conversions and that omissions are surfaced.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.