(I’ve prototyped this but posting here for more visibility.)
I propose we create
ModuleLike interfaces for the purposes of optimization and export (e.g. ExportVerilog).
ModuleLike being roughly analogous to
Rationale: frontend language dialects and other dialects will likely want/need to create their own instance and module ops. I expect these to largely be supersets of
hw.instance. (The HW dialect already has three
hw.module.generated. This would obviate the need for most of the helper functions in
HWOps.h.) While they could be lowered to the supported
hw ops, there are a few reasons authors may not want to:
- Loss of structured information. Alternate instance and module ops will contain additional information (if only the operation name). In order to export to verilog, one currently has to run a module through multiple passes and run ExportVerilog, which requires lowing to
hw.instance. One may want/need to persist the additional information across those passes (I’m assuming ExportVerilog is read-only w/ respect to the IR). E.g. placement data and other “metadata”.
- Using existing optimizations. Just like
FunctionLikeallows for inlining of arbitrary function-like ops, alternative instance and module ops will likely be amenable to some of the same optimizations/analyses which
hw.instanceare. Premature lowering, however, may prevent further op-specific optimizations and exports.
What do y’all think?
Alternatively, could we just use
FunctionLike and add an
InstanceLike (since there doesn’t seem to be a
CallLike in MLIR)? I don’t think that would be wise, but could be convinced otherwise.