How to get type alias printings in MLIR IR?

Hi all,
I have the following IR with type alias:

!alias_ptr = !emitc.ptr<f32>
%v0 = "emitc.variable"() {value = #emitc.opaque<"">} : () -> !alias_ptr

After I have put it into mlir-opt utility input “mlir-opt ./emitc.mlir”, the printed output was:

module {
    %0 = "emitc.variable"() {value = #emitc.opaque<"">} : () -> !emitc.ptr<f32>
}

Is it possible to get IR with alias printed instead of type, i.e. to get the IR like

%0 = "emitc.variable"(){value = #emitc.opaque<"">} : () -> !alias_ptr

?

As far as I know this is not possible, though it’s a feature I have also wanted for a while, as I have attributes that are a few hundred characters, and it would make the textual IR much easier to read.

Such a pity :sleepy:

For completness sake: This is possible but only as the owner of the dialect. To do this the dialect has to implement OpAsmDialectInterface and override getAlias to return anything but NoAlias when wanting to creating an alias for a type or attribute (MLIR: mlir::OpAsmDialectInterface Class Reference).
There currently isn’t any other way I believe, so unless the dialect owning the type/attribute implements the aliasing for exactly the types and attributes you want it is indeed not possible without upstream changes

1 Like

Following this way has brought a success, thanks :pray:

Hi Markus,
Thank you for the useful advice, it helped.
Maybe you know, is there a way to get a type by its alias?
Let’s suppose that my code above works, so, is it possible to get type emitc.ptr using its string alias “alias_ptr” as a key?

Hello Oleg!

Maybe you know, is there a way to get a type by its alias?
Let’s suppose that my code above works, so, is it possible to get type emitc.ptr using its string alias “alias_ptr” as a key?

There is no such mechanism I’m afraid. The concept of aliasing that we are talking about here is pure syntax sugar that is only constructed prior to printing textual assembly. There is no persistent datastructure within the IR that keeps track of names of attributes and types.

It’s not easy to recommend what you should do instead without knowing your use-case. If this is for the purpose of having nominal typing in MLIR then I’d discourage the use of names in your type system as these are usually counter-productive to optimizations (and any type-safety is best handled in the language frontend). If this is for the purpose of code generation (lowering from an AST to IR), then its best you make the mapping yourself.

If you nevertheless need the name then you should consider making it part of the attribute/type. One can even make a mutable attribute/type where the name is the only thing uniquely identifying the attribute/type. I’d highly discourage this path however unless you need circular attributes or types.