Lines Matching refs:MLIR

5 MLIR supports multi-dimensional `vector` types and custom operations on those
9 MLIR today and operate on ssa-values of type `vector` along with pattern
13 proposal but rather a textual documentation of existing MLIR components along
20 captures the current codegen paths implemented in MLIR in the various existing
28 abstractions in MLIR.
30 ![`vector` Abstractions in MLIR](https://user-images.githubusercontent.com/10148468/71176949-e85ad0…
42 The existing MLIR `vector`-level dialects are related to the following bottom-up
62 1.  MLIR Rewrite Patterns applied by the MLIR `PatternRewrite` infrastructure to
66 2.  `Virtual Vector -> Hardware Vector` lowering is specified as a set of MLIR
91 cost-based lowering decisions in MLIR even for `LLVM`. Specialized `CPU`
93 optimizations of on different types that core MLIR supports (e.g. Scalable
214 first "super-vectorization" prototype was implemented, MLIR was nowhere near as
216 there is an opportunity to revisit vectorization in MLIR.
221 reused across dialects. In particular, MLIR allows the definition of dialects at
245 first-class n-D values in MLIR. The alternative name Tile has been proposed,
252 This section describes the tradeoffs involved in lowering the MLIR n-D vector
259 MLIR does not currently support dynamic vector sizes (i.e. SVE style) so the
262 and MLIR.
266 following the [LLVM LangRef](https://llvm.org/docs/LangRef.html). MLIR
268 `vector.insertelement`). Such ops operate exclusively on MLIR `n-D` `vector`
273 Consider a vector of rank n with static sizes `{s_0, ... s_{n-1}}` (i.e. an MLIR
274 `vector<s_0x...s_{n-1}xf32>`). Lowering such an `n-D` MLIR vector type to an
277 1.  Flattening to a `1-D` vector: `!llvm<"(s_0*...*s_{n-1})xfloat">` in the MLIR
280     `!llvm."[s_0x[s_1x[...<s_{n-1}xf32>]]]">` in the MLIR LLVM dialect.
304 The next sentence illustrates a recurrent tradeoff, also found in MLIR, between
311 When transposing this to MLIR, `llvm.getelementptr` works on pointers to `n-D`
319 flattened lowering of an MLIR n-D vector to an LLVM 1-D vector.
394 MLIR `n-D` vector types are currently represented as `(n-1)-D` arrays of `1-D`
397 `shufflevector` on `n-D` vectors in MLIR only support static indices. Dynamic
408     correspond to the HW. This level of MLIR codegen is related to register
412     operations from MLIR `k-D` vector types and operations to LLVM `1-D`
418 make those very explicit in MLIR and allow codegen to explore tradeoffs.
422 Decisions made at the MLIR level will have implications at a much later stage in
424 to modeling of register allocation and spilling to MLIR explicitly. Instead,
426 types, associated with costs that `PatterRewriters` at the MLIR level will be
427 able to target. Such costs at the MLIR level will be abstract and used for
434 start from either `1-D` or `n-D` vectors in MLIR and use `vector.cast` to
456 extra MLIR patterns and costs.
467 and operations are implemented with LLVM intrinsics. In contrast, MLIR sits at a
469 generic n-D vector types from MLIR to aggregates of 1-D LLVM vectors. In the
471 even though MLIR will continue needing higher level abstractions.
473 On the other hand, one should note that as MLIR is moving to LLVM, this document
483 However MLIR codegen operates at a higher level of abstraction where we want to
489 lowering from MLIR because: