[Feature]: Proposal: Per-backend Conversion pass layout (FlyToROCDL/Passes.td + Passes.h.inc) for extensibility

[Peter9606]

Suggestion Description

Summary

Suggest refactoring the Conversion pass infrastructure so that each backend has its own TableGen definition and generated .inc files (e.g. flydsl/Conversion/FlyToROCDL/Passes.td and flydsl/Conversion/FlyToROCDL/Passes.h.inc), instead of a single shared Conversion/Passes.td and Conversion/Passes.h.inc. This would make it easier to add and maintain additional backends (e.g. FlyToNVVM, FlyToSPIRV) without touching a global Conversion tablegen setup.

Current design

• Single TableGen source: include/flydsl/Conversion/Passes.td defines all conversion passes (currently only FlyToROCDLConversionPass).
• Single generated header: TableGen produces one Conversion/Passes.h.inc used by:
  • Conversion/FlyToROCDL/FlyToROCDL.h (pass declaration)
  • Conversion/Passes.h (pass registration)
  • lib/Conversion/FlyToROCDL/FlyToROCDL.cpp (pass definition)

Adding a new backend (e.g. FlyToNVVM) would require editing this shared Passes.td and sharing the same Passes.h.inc, which mixes all backends in one place and can make ownership and code review less clear.

Proposed design

• Per-backend TableGen: Each conversion backend has its own directory with:

  • Passes.td – defines only that backend’s pass(es)
  • CMakeLists.txt – runs TableGen to generate Passes.h.inc (and optionally C API .inc files) in that directory
  • A dedicated tablegen target (e.g. FlyToROCDLPassIncGen)

• Include path: Backend code includes its own generated header, e.g.
  #include "flydsl/Conversion/FlyToROCDL/Passes.h.inc"
  instead of
  #include "flydsl/Conversion/Passes.h.inc".

• Conversion layer: Conversion/CMakeLists.txt only adds subdirectories (e.g. add_subdirectory(FlyToROCDL)). A central Conversion/Passes.h can still aggregate registration by including each backend’s Passes.h.inc with GEN_PASS_REGISTRATION.

Benefits

1. Extensibility: Adding a new backend (e.g. FlyToNVVM) is a self-contained change: new directory, own Passes.td and CMake, plus one line in Conversion/Passes.h and in Conversion/CMakeLists.txt. No edits to existing backend TableGen or shared .inc files.
2. Clear ownership: Each backend’s pass definition and generated code live under that backend’s folder, which simplifies reviews and navigation.
3. Consistency: Aligns with the idea of one conversion target per directory (e.g. FlyToROCDL/, future FlyToNVVM/), and matches patterns used elsewhere (e.g. Dialect/Fly/Transforms/ with its own Passes.td and Passes.h.inc).

Suggested directory layout (after refactor)

include/flydsl/Conversion/
├── CMakeLists.txt                 # add_subdirectory(FlyToROCDL), add_subdirectory(FlyToNVVM), ...
├── Passes.h                       # Central registration: include each backend's Passes.h.inc + GEN_PASS_REGISTRATION
└── FlyToROCDL/
    ├── CMakeLists.txt             # TableGen for this backend → Passes.h.inc (and capi if needed)
    ├── Passes.td
    └── FlyToROCDL.h               # include "flydsl/Conversion/FlyToROCDL/Passes.h.inc"

Migration steps (for FlyToROCDL)

1. Add Conversion/FlyToROCDL/Passes.td with the FlyToROCDLConversionPass definition (moved from Conversion/Passes.td).
2. Add Conversion/FlyToROCDL/CMakeLists.txt to run TableGen for this backend and add a target (e.g. FlyToROCDLPassIncGen).
3. Update Conversion/CMakeLists.txt to add_subdirectory(FlyToROCDL) and remove the previous single-file TableGen for Conversion/Passes.td.
4. Update FlyToROCDL.h, Conversion/Passes.h, and lib/Conversion/FlyToROCDL/FlyToROCDL.cpp to include flydsl/Conversion/FlyToROCDL/Passes.h.inc.
5. Update lib/Conversion/FlyToROCDL/CMakeLists.txt to depend on FlyToROCDLPassIncGen instead of the old Conversion-wide tablegen target.
6. Remove the now-unused Conversion/Passes.td.

Optional

If the project already uses a single Conversion C API tablegen, that can be moved to each backend (e.g. generate Passes.capi.*.inc from FlyToROCDL/Passes.td with the same prefix) so C API and pass layout stay consistent per backend.

---

I can contribute a patch for the FlyToROCDL refactor if this direction is acceptable to the maintainers.

Operating System

No response

GPU

No response

ROCm Component

No response

[sjfeng1999]

Great idea. It's already under consideration. The lowering pipeline may still undergo some adjustments — we'll probably rethink it once things stabilize.

[xiangzh1]

+1 for this suggestion