[Mlir-commits] [mlir] [mlir][Vector] Infer mask and pass_thru types for maskedload/store (PR #131482)

Kunwar Grover llvmlistbot at llvm.org
Wed Mar 19 05:15:28 PDT 2025


Groverkss wrote:

> Sure, things take some getting used to, and perhaps over time, the proposed format would feel more natural. However, I’m particularly concerned about newcomers to Vector. IMHO, they would likely find this quite confusing - is there a clear way to map each type to its corresponding argument?

I don't think this is a strong argument against this change. We have proper documentation for how types are. We have documentation on the assembly format. The tablegen format explicitly documents how arguments are infered, it's not some C++ magic, it's explicitly written in the tablegen file:

```c++
      AllTypesMatch<["result", "pass_thru"]>,
      TypesMatchWith<"mask shape should match result shape",
        "result",
        "mask",
        "VectorType::get(::llvm::cast<VectorType>($_self).getShape(),"
          "IntegerType::get($_ctxt, 1),"
          "::llvm::cast<VectorType>($_self).getScalableDims())">,
      AllElementTypesMatch<["result", "base"]>
```

This is very explicit in how the types are infered.

> But isn’t this what we want to avoid? If the distinction between vector.load and vector.maskedload becomes too blurred, it may lead to more confusion rather than clarity.

Adding redundant type infromation to an op to improve distinction between another op does not seem like good IR design to me.

> Some of these things are a matter or personal preference - I've tried to explain my reasoning so that you know where I am coming from. I think that it would be good to hear from more people.

I'm only looking to remove redundant information from IR here. These things are documented properly.

Do you have a strong preference here? I do have a strong preference here for having less redundent information in the IR here.

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


More information about the Mlir-commits mailing list