[mlir][Vector] Minor formatting fixes in Vector.md

[nicolasvasilache]

Thanks @michalt !
Do you have commit access or should I land this for you?

[michalt]

In D113854#3131332, @nicolasvasilache wrote:

Thanks @michalt !
Do you have commit access or should I land this for you?

I don't, so it'd be great if you could land it :) Thanks!

mlir/docs/Dialects/Vector.md

 reasonable to have the same levels of abstraction for all targets and perform
 cost-based lowering decisions in MLIR even for `LLVM`. Specialized `CPU`
 dialects that would capture specific features not well captured by LLVM peephole
 optimizations of on different types that core MLIR supports (e.g. Scalable
 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>
 
 %1 = vector.extract %0[1]: vector<3x7x8xf32> // -> vector<7x8xf32> %1 =
 vector.extract %0[1, 5]: vector<3x7x8xf32> // -> vector<8xf32> %2 =
 vector.outerproduct %0, %1: vector<4xf32>, vector<8xf32> // -> vector<4x8xf32>
 %3 = vector.outerproduct %0, %1, %2: vector<4xf32>, vector<8xf32> // fma when
 adding %2 %3 = vector.strided_slice %0 {offsets = [2, 2], sizes = [2, 2],
 strides = [1, 1]}: vector<4x8x16xf32> // Returns a slice of type
 vector<2x2x16xf32>
 
 %2 = vector.transfer_read %A[%0, %1] {permutation_map = (d0, d1) -> (d0)}:
 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
 [VectorOps.td](https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Dialect/Vector/VectorOps.td)
 ODS file (markdown documentation is automatically generated locally when
 building and populates the
 [Vector doc](https://github.com/llvm/llvm-project/blob/main/mlir/docs/Dialects/Vector.md)).
 Recent extensions are driven by concrete use cases of interest. A notable such

 ### Flattened 1-D Vector Type
 
 Pros:
 
 1.  `insertelement` / `extractelement` / `shufflevector` with dynamic indexing
     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
 
 #### HW Vectors and Implications on the SW and the Programming Model
 
 As of today, the LLVM model only support `1-D` vector types. This is
 unsurprising because historically, the vast majority of HW only supports `1-D`
 vector registers. We note that multiple HW vendors are in the process of

 stalled until recently. In its current form, it is limited to 2-D matrix types
 and operations are implemented with LLVM intrinsics. In contrast, MLIR sits at a
 higher level of abstraction and allows the lowering of generic operations on
 generic n-D vector types from MLIR to aggregates of 1-D LLVM vectors. In the
 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
 
 The flattened 1-D vector design in the LLVM matrix proposal is good in a
 HW-specific world with special intrinsics. This is a good abstraction for
 register allocation, Instruction-Level-Parallelism and
 SoftWare-Pipelining/Modulo Scheduling optimizations at the register level.
 However MLIR codegen operates at a higher level of abstraction where we want to