Lines Matching full:linalg

1 # Linalg Dialect Rationale: The Case For Compiler-Friendly Custom Operations
12 that led to the existing implementation of Linalg and aims at exposing
16 Linalg is designed to solve the High-level Hierarchical Optimization
26 this doc and the architecture of Linalg can help inform the community on a
31 Linalg started as a pragmatic dialect to bootstrap code generation in MLIR, by
34 into fast library implementations when available. Linalg **defines ops and
44 However, as the design of Linalg co-evolved with the design of MLIR, it became
48 The design and evolution of Linalg follow a *codegen-friendly* approach where
55 necessary. For example, `linalg.matmul` remains `linalg.matmul` after tiling
58 Furthermore, Linalg decouples transformation validity from profitability
64 [Linalg section](https://llvm.org/devmtg/2019-04/slides/Tutorial-AminiVasilacheZinenko-MLIR.pdf)
74 among others. The approach adopted by Linalg was extended to become
77 with Linalg becoming its incarnation on tensors and buffers.
81 design principles as Linalg. (Vector dialect includes the higher-level
85 The Linalg dialect itself grew beyond linear algebra-like operations to become
92 Linalg design remains open to evolution and cross-pollination with other
96 - the `!linalg.view` type folded into the *"Strided MemRef"* type while
99 - the `linalg.view` and `linalg.subview` ops evolved into the standard dialect;
100 - the `linalg.for`, `linalg.load` and `linalg.store` ops evolved into a prelude
105 Several [design questions](../Dialects/Linalg/_index.md/#open_issues) remain
106 open in Linalg, which does not claim to be a general solution to all compilation
112 "Linalg" could remove some of the confusions related to the dialect (and the
116 Linalg draws inspiration from decades of prior art to design a modern a
118 projects that influenced Linalg design:
149 implications of adopting any of the existing solutions, Linalg had the
153 The following reflections on prior art have influenced the design of Linalg.
155 behind Linalg.
162 Similarly to ONNX, Linalg defines *"semantically charged" named ops*.
167 Linalg hopes to additionally address the following:
182 Similarly to LIFT, Linalg uses local rewrite rules implemented with the MLIR
186 Linalg builds on, and helps separate concerns in the LIFT approach as follows:
194 LIFT is expected to further influence the design of Linalg as it evolves. In
216 Similarly, Linalg ops *"know their semantics"* and *"know how to transform and
220 Linalg hopes to additionally address the following:
253 Linalg hopes to additionally address the following:
301 Linalg hopes to additionally address the following:
367 compilers. Linalg intends to use this information when available and ensure
376 Affine dialects in particular, Linalg takes the following decisions.
397 them. Linalg focuses tiling on the data space instead, creating views into the
400 - **Preserve high-level information**: Linalg maintains the information provided
406 Given these choices, Linalg intends to be a better fit for **high-level
410 and is used as a lowering target for Linalg, enabling further transformations
411 and combination of semantically-loaded and lower-level inputs. As such, Linalg
417 The purpose of the Linalg IR and its operations is primarily to:
495 Instead, certain Linalg ops are designed to maintain high-level information
499 Linalg fully embraces this notion and thinks of codegen in terms of
502 Linalg ops (i.e. how heavy or lightweight the Linalg op is).
503 Linalg-based codegen and transformations start from higher-level IR
505 potential by introducing lower-level IR ops and *smaller* Linalg ops.
539 Still, this does not mean Linalg refuses cost models: instead we
564 The following key observations have influenced the design of Linalg and helped
571 design of Linalg: control-flow does not exist in a vacuum, independently of
575 [semantics of Linalg Ops](../Dialects/Linalg/_index.md/#linalg_ops) and their
578 manipulation, - on Linalg ops attributes or on loops after some partial lowering
579 occurred, - as extensions to the Linalg dialect in terms of new ops or
598 Despite the fact that Linalg ops only allow perfectly nested
607 In contrast, Linalg advocates for ***monotonicity*** under
621 [Linalg Dialect](../Dialects/Linalg/_index.md) and its future evolutions aspire