[ExportVerilog] Make ExportVerilog robust for HWModuleLike, NFC

[uenoku]

This is separated from #6977. This changes pre-passes for ExportVerilog to run on HWModuleLike instead of HWModuleOp. #6977 is going to add a support for SV func op and legalization needs to be ran on SV func as well.

[teqdruid]

I'm not sure this is a good idea. Ops that implement hwmodulelike don't necessarily have semantics which directly map to systemverilog semantics. Have you searched for ops that implement it to ensure that we want them to be directly emitted to verilog?

To be clear, I'm not sure it's a bad idea either.

[uenoku]

Thank you for the feedback and that's good point. I thought HWModuleOps feed into ExportVerilog are assumed to be emittable as SV but I agree that it would be nicer to explicitly check that.

I'd like to propose to use Emittable trait

circt/include/circt/Dialect/Emit/EmitOpInterfaces.td

Lines 18 to 20 in 7073e2c

	def Emittable : NativeOpTrait<"Emittable"> {
	let cppNamespace = "::circt::emit";
	}

and run PrepareForEmission on HWModuleLike with Emittable trait (or extend Emittable trait to op interface).

[teqdruid]

Thank you for the feedback and that's good point. I thought HWModuleOps feed into ExportVerilog are assumed to be emittable as SV but I agree that it would be nicer to explicitly check that.

I'd like to propose to use Emittable trait

circt/include/circt/Dialect/Emit/EmitOpInterfaces.td

Lines 18 to 20 in 7073e2c

	def Emittable : NativeOpTrait<"Emittable"> {
	let cppNamespace = "::circt::emit";
	}

and run PrepareForEmission on HWModuleLike with Emittable trait (or extend Emittable trait to op interface).

Does ExportVerilog / PrepareForEmission already depend on (know about) the Emission dialect?

I'm more comfortable with HWModuleLike ops to have to opt-in to Emittable. I'd be even more comfortable if Emittable were an OpInterface with a bool emittedToVerilog() method.

This raises the question: why do we want all HWModuleLike ops to be capable of being emitted to Verilog? Why not lower them into HWModuleOps? Is there a specific use-case?

[teqdruid]

Or is this intended for preparation only? In that case, I think that any op which implements a future method like Emittable.shouldBePreparedForSVEmission() (or whatever name) should get legalized -- regardless of whether or not it implements HWModuleLike. Given that you probably need things like ports when preparing, though, this can be considered future work so long as it's documented as a restriction.

[uenoku]

Does ExportVerilog / PrepareForEmission already depend on (know about) the Emission dialect?

Yes.

This raises the question: why do we want all HWModuleLike ops to be capable of being emitted to Verilog? Why not lower them into HWModuleOps? Is there a specific use-case?

sv.func is the first use case that is not HWModuleop and also needs PrepareForeEmission. HWModuleLike provides sufficient interface for PrepareForEmisson especially regarding port name legalization.

Or is this intended for preparation only?

Yes. PrepareForEmission and probably PrettifyVerilog.

[teqdruid]

ok. I have no problem with this assuming that you do something with the Emittable trait.