[Mlir-commits] [mlir] [mlir][IR] Add `VectorTypeElementInterface` with `!llvm.ptr` (PR #133455)

[Andrzej Warzyński]

================
@@ -16,7 +16,36 @@
 
 include "mlir/IR/OpBase.td"
 
-def FloatTypeInterface : TypeInterface<"FloatType"> {
+//===----------------------------------------------------------------------===//
+// VectorElementTypeInterface
+//===----------------------------------------------------------------------===//
+
+def VectorElementTypeInterface : TypeInterface<"VectorElementTypeInterface"> {
+  let cppNamespace = "::mlir";
+  let description = [{
+    Implementing this interface establishes a contract between this type and the
+    vector type, indicating that this type can be used as element of vectors.
+
+    Vector element types are treated as a bag of bits without any assumed
+    structure. The size of an element type must be constant, but it does not
+    necessarily have to be a compile-time constant.
----------------
banach-space wrote:

> The vector.bitcast verifier looks up the bitwidth of the source/result types in the closest DataLayout. I think that should work as is.

Indeed, I missed that, thanks! ([link](https://github.com/llvm/llvm-project/blob/0fc7aec349394d4713bd88fb5f0319e39b96f187/mlir/lib/Dialect/Vector/IR/VectorOps.cpp#L5825-L5828))

> Yes, this is about intermediate transformations. At the very end, when emitting machine code, the size must be known.

In my mental model, the width is always a "compile-time constant" in the sense that it cannot change during compilation - but it might still be unknown at certain stages if it's not needed. So, something along the lines of:

> The size of an element type must be a compile-time constant, but the bit-width might remain opaque or unavailable during transformations where it’s not required.

To illustrate my thinking: take scalable vectors. The actual vector width is unknown at **compile-time**, but fixed at **run-time**. This doesn't imply that the width (i.e. num elements) is mutable during compilation - it just means we don't need to know it until later.

Similarly (though unrelated to scalable vectors per se), I see this situation as:

> The actual bit-width might be unknown at transformation-time, but must be fixed at machine-code generation time.

That bit-width is not mutable at transformation time - it’s fixed - but we don’t need to resolve it until later. So in that sense, it's still a constant, even if it hasn’t been “materialised” yet.

I hope I’m not splitting hairs 😅 I'm just keen to be semantically tight and precise here.

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