[Mlir-commits] [mlir] [mlir][emitc] Restrict types in EmitC (PR #88391)

[Matthias Gehre]

mgehre-amd wrote:

> > We have had these discussions several times online and offline (already during upstreaming the dialect and the emitter), and the consensus was to make the dialect robust and keep the emitter simple. As @mgehre-amd mentioned, types that are not supported by the emitter can be represented with `!emitc.opaque<"mytype">`. Of course we are also happy to discuss if it makes sense to add support for further types to the dialect / emitter.
> 
> Just to clarify, does this mean that the right way to have a call to a function with unsupported types is to first `emit.cast` them into opaque types? What's breaking for us right now is an `emitc.opaque_call` to a function that takes bf16 vectors as parameters, and I'm trying to figure out what's the right thing to do here 😅
> 
> Edit: I've tried the casting approach, and the only thing that seems to be working for me is injecting `unrealized_conversion_cast`, which is an issue because it won't be reconciled in any natural way. Am I right to understand that the use we're abusing `emitc` with the use we're making of it? Is there a nicer way to interface with non-emitc types?

emitc is about emitting C code, so the first question becomes: How should a `vector of bf16` be spelled in the C code? You then put that spelling into a `!emitc.opaque`, e.g. ``!emitc.opaque<"myvector<mybf16>">`. And then you have to use that everywhere in the emitc IR (which typically means that you will use a `TypeConverter` during dialect conversion).
You cannot use `emitc.cast` to convert an illegal type into an `!emitc.opaque`, because then the `cast` couldn't be emitted as C code.

https://github.com/llvm/llvm-project/pull/88391