# Move / Remove \`vcix\` dialect

**URL:** <https://discourse.llvm.org/t/move-remove-vcix-dialect/86920>\
**Category:** MLIR\
**Tags:** riscv\
**Created:** [June 17, 2025, 11:19am UTC](https://discourse.llvm.org/t/move-remove-vcix-dialect/86920 "2025-06-17T11:19:02Z")\
**Posts on this page:** 1\
**Showing post:** 46

<div class="post-metadata">

**Author:** ![mshockwave](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/mshockwave/32/13674_2.png) [@mshockwave](https://discourse.llvm.org/u/mshockwave)\
**Post date:** [June 23, 2025, 7:12am UTC](https://discourse.llvm.org/t/move-remove-vcix-dialect/86920/46 "2025-06-23T07:12:48Z")

</div>

(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.

---

_[View the full topic](https://discourse.llvm.org/t/move-remove-vcix-dialect/86920)._