Move / Remove `vcix` dialect

[mshockwave]

(My apologies if I can’t quote a specific comment)

On the topic of low-level “intrinsic” dialect, in addition to modeling some target-specific operations, another thing that I thought will be useful for such dialects would be type legalization: take RISC-V as an example, it only supports a subset of (scalable) vector types. If we want to generate RISC-V intrinsics directly from MLIR side, regardless of using a dedicated dialect or not, those intrinsic need to use legalized types.

If there is a low-level intrinsic dialect for, said RVV intrinsics, then such legalization can be easily implemented with the existing conversion framework. This applies to the case when there is a high-level RISC-V dialect added in the future. If we want to adopt Proposal #2’s approach to lower any higher level dialects directly to LLVMIR intrinsics, that – please correct me if I’m wrong – I think we kind of have to roll our own type legalizer in this conversion, or at least adding many custom conversion rules.

I’m not sure whether type legalization for generating target-specific intrinsics in MLIR is a huge problem for other architectures like ARM SVE, but it’s kind of a pain for RISC-V – maybe it’s because we support less number of legal vector types so we have to think about this problem early on.

@rengolin

Proposal #1: We converge to namespaces for extensions

This has a similar code-cost as multiple dialects, but condenses the extensions into one place, so that developers know where to look and what they are. A non-RV developer won’t be wondering what the vcix dialect is, and all RV developers will look for that namespace inside the rvv dialect.

Agree on the fact that the name “vcix” by itself is pretty confusing for non RISC-V developers.

@rengolin

Proposal #2: We move all CPU intrinsics inside the high-level dialect

This is mostly the case already, just making it the case for RISC-V. It may feel like increase in code-cost now (because currently the vcix dialect is thinner than an rvv dialect would be, but the long-term maintainability and discoverability would increase with more extensions added.

I do believe the RV community should be able to add as many extensions as they want without the issue of polluting the dialect soup.

I understand that there isn’t any high-level RISC-V dialects at this moment so we can only talk about hypothetic situation here. But I have previously expressed my concern on potentially not being able to use the conversion framework to do legalization

@rengolin

Proposal #3: We converge to one dialect per architecture

Here, we’d merge amx and x86vector into a single x86 dialect, with namespaces for each extension. Similar for the arm variants, and create a new rvv (or other name) for RISC-V, so we don’t explode the dialect soup.

Also related:

@rengolin

@jpienaar

Especially for ones that are very configurable (e.g., if all the RiscV matrix extensions is in one dialect, I can mark them illegal in dialect conversion by marking the “sub” dialect illegal,

We already have that in x86 and Arm. It won’t be different for RiscV. Target selection is a property of the target, not the dialect. If DLTI knows about a particular target, then I can instantiate a class about that target and let all the decisions be done at the sub-group level.

Sub-grouping is something I’m not really familiar with so please correct me if I’m wrong: with that approach does that mean individual dialect needs to do things like marking and filtering out illegal operations by themselves?

Similar to @jpienaar originally I also thought separating each extension into its own dialects would be way easier (just mark the unsupported extension as illegal and MLIR will take care of the rest). Sure, it might bloat the compiler size but I thought that’s a technical issue we can solve iteratively.

I think all proposals and discussions we have here are pretty helpful for establishing a rigid framework or convention for future target-specific dialect in this space. Especially for RISC-V with its enormous number of extensions, I’m sure similar topics on abstraction level / extensibility will be brought up again and again.