[mlir][vector][doc] 0D vectors #73792
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@llvm/pr-subscribers-mlir Author: Rik Huijzer (rikhuijzer) ChangesCurrently, the only mention of 0d vectors in the MLIR source code that I could find was: > 0D vectors are allowed by omitting the dimension: in 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. Full diff: https://github.com/llvm/llvm-project/pull/73792.diff 1 Files Affected:
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
|
rikhuijzer
requested review from
matthias-springer,
c-rhodes and
nicolasvasilache
joker-eph
approved these changes
Nov 29, 2023
nicolasvasilache
approved these changes
Nov 30, 2023
banach-space
added a commit
to banach-space/llvm-project
that referenced
this pull request
Aug 3, 2024
The link has been broken since llvm#73792. I've also rephrased the comment a bit to better match the updated section heading.
banach-space
added a commit
that referenced
this pull request
Aug 5, 2024
The link has been "broken" since #73792 that updated "## DeeperDive" to "## LLVM Lowering Tradeoffs". This patch fixes the MD link for the affected sub-section: * Before: [deeper dive section](#DeeperDive) * After: [LLVM Lowering Tradeoffs](#llvm-lowering-tradeoffs) I've also rephrased the surrounding comment a bit - to better match the updated section name.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the only mention of 0d vectors in the MLIR source code that I could find was:
in
BuiltinTypes.td.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.