[Mlir-commits] [mlir] [mlir][vector][doc] 0D vectors (PR #73792)

[Rik Huijzer]

https://github.com/rikhuijzer created https://github.com/llvm/llvm-project/pull/73792

Currently, the only mention of 0d vectors in the MLIR source code that I could find was:

>     0D vectors are allowed by omitting the dimension: `vector<f32>`.

in [`BuiltinTypes.td`](https://github.com/llvm/llvm-project/blob/437a48b2d9bfc6e38a0ca43f1cee48ceaf0fe249/mlir/include/mlir/IR/BuiltinTypes.td#L1046-L1047).

This patch adds a summary of https://discourse.llvm.org/t/what-is-the-semantics-of-memref-0xf32-and-tensor-0xf32/3557 and https://discourse.llvm.org/t/should-we-have-0-d-vectors/3097/5.

>From 4d60c90021cee79b0383d1c45272b422a85d2e23 Mon Sep 17 00:00:00 2001
From: Rik Huijzer <github at huijzer.xyz>
Date: Wed, 29 Nov 2023 13:50:42 +0100
Subject: [PATCH] [mlir][vector][doc] 0D vectors

---
 mlir/docs/Dialects/Vector.md | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/mlir/docs/Dialects/Vector.md b/mlir/docs/Dialects/Vector.md
index a907d59566366bb..6d05d9b90467662 100644
--- a/mlir/docs/Dialects/Vector.md
+++ b/mlir/docs/Dialects/Vector.md
@@ -247,7 +247,19 @@ which conveys higher-D meaning. But it also is one of the most overloaded terms
 in compilers and hardware. For now, we generally use the `n-D` `vector` name and
 are open to better suggestions.
 
-## DeeperDive
+## 0D Vectors
+
+Vectors of dimension 0 (or _0-D vectors_ or _0D vectors_) are allowed inside
+MLIR. For instance, a `f32` vector containing one scalar can be denoted as
+`vector<f32>`. This is similar to the `tensor<f32>` type that is available in
+TensorFlow or the `memref<f32>` type that is available in MLIR.
+
+Generally, a 0D `vector` can be interpreted as a scalar. The benefit of 0D
+`vector`s, `tensor`s, and `memref`s is that they make it easier to lower code
+from various frontends such as TensorFlow and make it easier to handle corner
+cases such as unrolling a loop from 1D to 0D.
+
+## LLVM Lowering Tradeoffs
 
 This section describes the tradeoffs involved in lowering the MLIR n-D vector
 type and operations on it to LLVM-IR. Putting aside the