Lines Matching refs:MLIR

5 MLIR supports multi-dimensional `vector` types and custom operations on those
9 in MLIR today and operate on ssa-values of type `vector` along with pattern
13 new proposal but rather a textual documentation of existing MLIR components
19 captures the current codegen paths implemented in MLIR in the various existing
27 abstractions in MLIR.
29 ![`vector` Abstractions in MLIR](https://user-images.githubusercontent.com/10148468/71176949-e85ad0…
40 The existing MLIR `vector`-level dialects are related to the following
60 1. MLIR Rewrite Patterns applied by the MLIR `PatternRewrite` infrastructure
64 2. `Virtual Vector -> Hardware Vector` lowering is specified as a set of MLIR
89 abstraction for all targets and perform cost-based lowering decisions in MLIR
92 captured by LLVM peephole optimizations of on different types that core MLIR
201 is that when the first "super-vectorization" prototype was implemented, MLIR
204 in MLIR.
209 be reused across dialects. In particular, MLIR allows the definition of
234 `vector`s are first-class n-D values in MLIR.
243 This section describes the tradeoffs involved in lowering the MLIR n-D vector
250 MLIR does not currently support dynamic vector sizes (i.e. SVE style) so the
253 in LLVM and MLIR.
258 MLIR operations are prefixed by the `vector.` dialect prefix
259 (e.g. `vector.insertelement`). Such ops operate exclusively on MLIR `n-D`
264 MLIR `vector<s_0x...s_{n-1}xf32>`). Lowering such an `n-D` MLIR vector type to
268 MLIR LLVM dialect.
270 `!llvm<"[s_0x[s_1x[...<s_{n-1}xfloat>]]]">` in the MLIR LLVM dialect.
298 The next sentence illustrates a recurrent tradeoff, also found in MLIR,
308 When transposing this to MLIR, `llvm.getelementptr` works on pointers to `n-D`
316 flattened lowering of an MLIR n-D vector to an LLVM 1-D vector.
387 MLIR `n-D` vector types are currently represented as `(n-1)-D` arrays of `1-D`
391 vectors in MLIR only support static indices. Dynamic indices are only
402 correspond to the HW. This level of MLIR codegen is related to register
406 operations from MLIR `k-D` vector types and operations to LLVM `1-D` vectors +
412 prefer to make those very explicit in MLIR and allow codegen to explore
417 Decisions made at the MLIR level will have implications at a much later stage
419 related to modeling of register allocation and spilling to MLIR
422 MLIR level will be able to target. Such costs at the MLIR level will be
428 can start from either `1-D` or `n-D` vectors in MLIR and use `vector.cast` to
451 with extra MLIR patterns and costs.
461 In contrast, MLIR sits at a higher level of abstraction and allows the
462 lowering of generic operations on generic n-D vector types from MLIR to
465 also for CPU even though MLIR will continue needing higher level abstractions.
467 On the other hand, one should note that as MLIR is moving to LLVM, this
477 However MLIR codegen operates at a higher level of abstraction where we want
483 lowering from MLIR because: