Its seems reasonable to me that the annotation be added to the ops first. I guess for now it is “expected” that the operands are sparse the “right” way, i.e. there is no check to ensure the tensors match up?
My main question is would this eventually make it to the type itself, i.e. the tensor type has extra information that would effectively represent the same information as the sparse_map and this attribute would become unnecessary?
The “sparse compiler” part will verify the consistency of the annotation. If a tensor appears twice in a kernel, for example, the annotation should be consistent. Otherwise it is rejected. We probably also want to add an affine map to specify index order on tensors (viz. TACO’s way of defining requires (1) per-dimension annotation, (2) dimension order for each tensor).
Yes, eventually we need to design a proper type system which would obsolete (or at least imply) the annotation I propose above. The current solution is pragmatic: it allows me to start prototyping this idea starting from a Linalg expression. Eventually, all ends need to be connected to get an end-to-end solution working.
Dr. Gokcen Kestor will give a presentation titled “Code generation for sparse computational kernels in MLIR” on Dec 2, 2020, at 10am. Everyone who signed up by email will receive a Google Meet invite with more information. I personally look forward to this talk!
I have been following this discussion through my PhD student John Jolly, but I wanted to take a moment to personally express interest in participating in this design and development effort on behalf of my research group and collaborators Michelle Strout (Univ. of Arizona) and Cathie Olschanowsky (Boise State). We have been working on sparse polyhedral optimization and code generation for some time (see, e.g., papers in CGO’14, PLDI’15, SC’16, PLDI’19), and we view MLIR as an opportunity to deploy support for sparse representations in widely-used framework and leverage other parts of the system.
The idea proposed by @aartbik of delaying binding of the sparse format mirrors what we are thinking. We are also interested in supporting the following:
As a PI on the DOE Exascale Computing Project, I am also interested in the role MLIR might have in building a software ecosystem for the HPC community. This is already happening to some extent with LLVM, but certain kinds of optimizations are difficult to do at lower levels of abstraction.
For now, we are monitoring what is happening on this thread and the design thread, and three of my students, including John Jolly, are testing out approaches for some of the objectives described above.
Thank you very much, Prof. Hall, for your reply and the background information. I should indeed have made it more clear in this thread that I also spun off another thread specifically for the MLIR work.
I look forward to the results of your students, and perhaps even some upstream contributions. Please let us know when you are ready to present something, either specifically to this sparse audience, or more general in our Open Design Meetings.
Welcome here @mhall 
It’s great to read this! This is really in line with the idea I was pushing in my keynote at the LLVM-HPC workshop last week (temporary links for slides and recording FYI, in particular the last 15min starting slides 41 or 50min in the recording). I’m really looking forward to this!
Many thanks to Dr. Kestor for giving a very interesting talk on “Code generation for sparse computational kernels in MLIR” (and thanks to our PM Pankaj for quickly making the recording publicly available).