[Mlircommits] [mlir] c47108c  [mlir][Vector] Minor formatting fixes in Vector.md
Nicolas Vasilache
llvmlistbot at llvm.org
Thu Nov 25 23:16:19 PST 2021
Author: Michal Terepeta
Date: 20211126T07:16:07Z
New Revision: c47108c0414624811684afc8d84697d434219f8c
URL: https://github.com/llvm/llvmproject/commit/c47108c0414624811684afc8d84697d434219f8c
DIFF: https://github.com/llvm/llvmproject/commit/c47108c0414624811684afc8d84697d434219f8c.diff
LOG: [mlir][Vector] Minor formatting fixes in Vector.md
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D113854
Added:
Modified:
mlir/docs/Dialects/Vector.md
Removed:
################################################################################
diff git a/mlir/docs/Dialects/Vector.md b/mlir/docs/Dialects/Vector.md
index 0763b8b43e14..514054e74372 100644
 a/mlir/docs/Dialects/Vector.md
+++ b/mlir/docs/Dialects/Vector.md
@@ 95,7 +95,9 @@ Vectors) are welcome future extensions.
### Virtual Vector Ops
Some existing Standard and Vector Dialect on `nD` `vector` types comprise: ```
+Some existing Standard and Vector Dialect on `nD` `vector` types comprise:
+
+```mlir
%2 = arith.addf %0, %1 : vector<3x7x8xf32> // > vector<3x7x8xf32> %2 =
arith.mulf %0, %1 : vector<3x7x8xf32> // > vector<3x7x8xf32> %2 = std.splat
%1 : vector<3x7x8xf32> // > vector<3x7x8xf32>
@@ 112,7 +114,8 @@ vector<2x2x16xf32>
memref<7x?xf32>, vector<4xf32>
vector.transfer_write %f1, %A[%i0, %i1, %i2, %i3] {permutation_map = (d0, d1,
d2, d3) > (d3, d1, d0)} : vector<5x4x3xf32>, memref<?x?x?x?xf32> ```
+d2, d3) > (d3, d1, d0)} : vector<5x4x3xf32>, memref<?x?x?x?xf32>
+```
The list of Vector is currently undergoing evolutions and is best kept track of
by following the evolution of the
@@ 342,12 +345,16 @@ Pros:
is possible over the whole lowered `nD` vector type.
2. Supports special intrinsics and native operations.
Cons: 1. Requires linearization/delinearization logic everywhere, translations
are complex. 2. Hides away the real HW structure behind dynamic indexing: at the
end of the day, HW vector sizes are generally fixed and multiple vectors will be
needed to hold a vector that is larger than the HW. 3. Unlikely peephole
optimizations will result in good code: arbitrary dynamic accesses, especially
at HW vector boundaries unlikely to result in regular patterns.
+Cons:
+
+1. Requires linearization/delinearization logic everywhere, translations are
+ complex.
+2. Hides away the real HW structure behind dynamic indexing: at the end of the
+ day, HW vector sizes are generally fixed and multiple vectors will be needed
+ to hold a vector that is larger than the HW.
+3. Unlikely peephole optimizations will result in good code: arbitrary dynamic
+ accesses, especially at HW vector boundaries unlikely to result in regular
+ patterns.
### Discussion
@@ 457,10 +464,8 @@ future, it could make sense to lower to the LLVM matrix abstraction also for CPU
even though MLIR will continue needing higher level abstractions.
On the other hand, one should note that as MLIR is moving to LLVM, this document
could become the unifying abstraction that people should target for

> 1D vectors and the LLVM matrix proposal can be viewed as a subset of this
> work.
+could become the unifying abstraction that people should target for 1D vectors
+and the LLVM matrix proposal can be viewed as a subset of this work.
### Conclusion
More information about the Mlircommits
mailing list