From: Michal Terepeta Date: Fri, 26 Nov 2021 07:14:07 +0000 (+0000) Subject: [mlir][Vector] Minor formatting fixes in Vector.md X-Git-Tag: upstream/15.0.7~24750 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=c47108c0414624811684afc8d84697d434219f8c;p=platform%2Fupstream%2Fllvm.git [mlir][Vector] Minor formatting fixes in Vector.md Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D113854 --- diff --git a/mlir/docs/Dialects/Vector.md b/mlir/docs/Dialects/Vector.md index 0763b8b..514054e 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 ``` +d2, d3) -> (d3, d1, d0)} : vector<5x4x3xf32>, memref +``` 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