[RFC] A Lightweight Debugging Dialect for MLIR

MLIR
1

Summary

This RFC proposes a small MLIR dialect called Arey, intended purely for printf-style debugging and runtime assertions inside MLIR IR. It provides simple ops like arey.print and arey.assert to help developers inspect values and catch errors during pass development, without depending on higher-level or execution dialects.

Motivation

MLIR developers frequently rely on ad-hoc print ops or temporary custom debugging utilities. There is no minimal, stable dialect dedicated to instrumentation. A tiny debugging dialect would:

  • simplify pass debugging

  • make debug IR explicit and portable

  • allow easy stripping for production builds

  • avoid mixing debugging logic with execution semantics

Proposed Ops

arey.print

  • Prints SSA values and/or a message.

  • Side-effecting, no results.

arey.assert

  • Asserts a boolean condition with optional message.

  • Lowerable to a simple abort/printf backend.

--arey--to--llvm

  • Converts arey to llvm

--remove-arey

  • Removes all arey instrumentation stub from the IR

Questions for Feedback

  1. Is a dedicated debugging dialect useful enough to include in MLIR?

  2. Should the dialect live inside MLIR or remain external?

  3. Is the scope (print + assert) sufficient, or should we add anything else?

  4. Expected interactions with existing debugging/tracing infrastructure?

Conclusion

Arey aims to be a tiny, practical debugging aid for MLIR IR. Feedback on scope, placement, and design is welcome.

2

Thanks for the proposal!
I’m interested in more details: you propose a “print” operation which takes a single operand without any type constraint: how is the lowering intended to work? For example: arep.print %t : tensor<2x5xf32> would have a non-trivial ABI.
Right now we already have such things in MLIR, have you seen vector.print and its lowering for example?

You also added an assert op, why not use cf.assert (or improve it)?

1 Like