[mlir][Vector] Minor formatting fixes in Vector.md
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D113854
GitOrigin-RevId: c47108c0414624811684afc8d84697d434219f8c
diff --git a/docs/Dialects/Vector.md b/docs/Dialects/Vector.md
index 0763b8b..514054e 100644
--- a/docs/Dialects/Vector.md
+++ b/docs/Dialects/Vector.md
@@ -95,7 +95,9 @@
### Virtual Vector Ops
-Some existing Standard and Vector Dialect on `n-D` `vector` types comprise: ```
+Some existing Standard and Vector Dialect on `n-D` `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 @@
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 @@
is possible over the whole lowered `n-D` 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 @@
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
-
-> 1-D 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 1-D vectors
+and the LLVM matrix proposal can be viewed as a subset of this work.
### Conclusion
