maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D113854
This commit is contained in:
Michal Terepeta 2021-11-26 07:14:07 +00:00 committed by Nicolas Vasilache
parent a1dc97e472
commit c47108c041
1 changed files with 17 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
mlir/docs/Dialects/Vector.md
View File

@ -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