[Mlir-commits] [mlir] c47108c - [mlir][Vector] Minor formatting fixes in Vector.md

[Nicolas Vasilache]

Author: Michal Terepeta
Date: 2021-11-26T07:16:07Z
New Revision: c47108c0414624811684afc8d84697d434219f8c

URL: https://github.com/llvm/llvm-project/commit/c47108c0414624811684afc8d84697d434219f8c
DIFF: https://github.com/llvm/llvm-project/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 `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 @@ 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 `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 @@ 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
-
-> 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