[PATCH] D73595: [mlir][Linalg][doc] Add Design Document for the Linalg Dialect

[River Riddle via Phabricator via llvm-commits]

rriddle added a comment.

Started making my way through it, very interesting doc!



================
Comment at: mlir/docs/Dialects/Linalg.md:3
 
-To generate the documentation:
+Table of contents:
+1. [Introduction: Inception and Evolution](#introduction)
----------------
It'd be really nice if we can use a TOC equivalent.


================
Comment at: mlir/docs/Dialects/Linalg.md:34
+        6. [Property 6: Perfectly Nested Writes To The Whole Output Operands](#prop6)
+        8. [Putting it Together](#summary)
+    2. [Data Representation: Views](#views)
----------------
Is there a 7?


================
Comment at: mlir/docs/Dialects/Linalg.md:47
+
+In his latest MLIR Open Design meeting presentation, Chris laid out a compelling
+[vision](https://drive.google.com/corp/drive/folders/1C3SEjO4u9E0UB2IwztSxaovFTSATDxT6)
----------------
This seems like it's going to be out-of-date soon and feels weird to include for the documentation of a dialect.


================
Comment at: mlir/docs/Dialects/Linalg.md:51
+the infrastructure and be driven by search. The MLIR Linalg dialect aims at bringing an answer 
+to the higher-level codegen problem.  This document describes the key design principles 
+that led to the existing implementation of Linalg and aims at exposing the tradeoffs 
----------------
Double space?


================
Comment at: mlir/docs/Dialects/Linalg.md:59
+the field, from which it seeks to learn key lessons. This documentation
+and introspection effort also comes in the context of the proposal for a
+working group for discussing the [Development of high-level Tensor Compute
----------------
This start of this paragraph seems like it's describing why you are writing this documentation, which seems weird for a doc about the dialect. 


================
Comment at: mlir/docs/Dialects/Linalg.md:74
+into fast library implementations when available. Linalg **defines ops and
+transformations declaratively**  and was originally restricted to ops with
+*linear-algebra like* semantics (`pointwise`, `matmul`, `conv`...). This
----------------
Extra space here.


================
Comment at: mlir/docs/Dialects/Linalg.md:92
+This information captures the legality and applicability of transformations and
+is **not lost by lowering prematurely to loop or CFG form**.  The key
+transformations are designed so as to **preserve this information** as long as
----------------
Extra space before "The"


================
Comment at: mlir/docs/Dialects/Linalg.md:118
+It is complemented by the
+[Vector dialect](https://mlir.llvm.org/docs/Dialects/Vector/),
+which define structured operations on vectors, following the same rationale and
----------------
Prefer relative paths on all of the things that can use it


================
Comment at: mlir/docs/Dialects/Linalg.md:140
+- the `linalg.for`, `linalg.load` and `linalg.store` ops evolved into a prelude
+to the *structured control flow* dialect (currently still named `LoopOps`).
+More components can be extracted, redesigned and generalized when new uses or
----------------
I'd remove "currently still"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73595/new/

https://reviews.llvm.org/D73595