[all-commits] [llvm/llvm-project] 7714b4: [mlir] introduce "encoding" attribute to tensor type

[Aart Bik via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7714b405a0de47e461c77fa8dbd2c21f0d34bbf2
      https://github.com/llvm/llvm-project/commit/7714b405a0de47e461c77fa8dbd2c21f0d34bbf2
  Author: Aart Bik <ajcbik at google.com>
  Date:   2021-04-12 (Mon, 12 Apr 2021)

  Changed paths:
    M mlir/include/mlir-c/BuiltinAttributes.h
    M mlir/include/mlir-c/BuiltinTypes.h
    M mlir/include/mlir/IR/BuiltinTypes.td
    M mlir/lib/Bindings/Python/IRAttributes.cpp
    M mlir/lib/Bindings/Python/IRTypes.cpp
    M mlir/lib/CAPI/IR/BuiltinAttributes.cpp
    M mlir/lib/CAPI/IR/BuiltinTypes.cpp
    M mlir/lib/IR/AsmPrinter.cpp
    M mlir/lib/IR/BuiltinTypes.cpp
    M mlir/lib/Parser/TypeParser.cpp
    M mlir/test/CAPI/ir.c
    M mlir/test/IR/invalid.mlir
    M mlir/test/IR/parser.mlir

  Log Message:
  -----------
  [mlir] introduce "encoding" attribute to tensor type

This CL introduces a generic attribute (called "encoding") on tensors.
The attribute currently does not carry any concrete information, but the type
system already correctly determines that tensor<8xi1,123> != tensor<8xi1,321>.
The attribute will be given meaning through an interface in subsequent CLs.

See ongoing discussion on discourse:

[RFC] Introduce a sparse tensor type to core MLIR
https://llvm.discourse.group/t/rfc-introduce-a-sparse-tensor-type-to-core-mlir/2944

A sparse tensor will look something like this:

```
// named alias with all properties we hold dear:
#CSR = {
  // individual named attributes
}

// actual sparse tensor type:
tensor<?x?xf64, #CSR>
```

I see the following rough 5 step plan going forward:

(1) introduce this format attribute in this CL, currently still empty
(2) introduce attribute interface that gives it "meaning", focused on sparse in first phase
(3) rewrite sparse compiler to use new type, remove linalg interface and "glue"
(4) teach passes to deal with new attribute, by rejecting/asserting on non-empty attribute as simplest solution, or doing meaningful rewrite in the longer run
(5) add FE support, document, test, publicize new features, extend "format" meaning to other domains if useful

Reviewed By: stellaraccident, bondhugula

Differential Revision: https://reviews.llvm.org/D99548