rocMLIR techniques vs Linalg

[sjw36]

List rocMLIR techniques and Linalg alternatives

[manupak]

1. Piece-wise affine map builders with some having validity checks in between
   • Pad to check things go oob and Embed to catch neg indices
2. index-diffs to get a delta in upper coordinate reflected to a bottom coordinate
3. Vector length inference

[sjw36]

rocMLIR techniques

1. Implicit GEMM
2. Coordinate transforms
3. Vectorization
4. SW Pipelining
5. Multi-buffering (not implemented yet)
6. Fusion capabilities
7. Reduction support
8. Attention

[manupak]

My suggestions are a level below - in line with what we discussed -- say if we had to lower tosa -> linalg -> ... -> AMDGPU/memref/vector for example

[sjw36]

yes, compare alternate lowering flows.

[manupak]

We (me and Giuseppe) had a chat with a person from AIE team.
He was quite interested in as to "why" we needed rock.transforms.

Firstly, they work on SSA.

Secondly, they get much of the views done via tensor.pack (can do perms, merge and unmerge)
and they haven't thought about pad but in the discussion felt like could use tensor.pad

They have not thought about embed -- I could not immediately map/find anything map this to upstream dialects.

[manupak]

Reviving this thread in anticipation for possible future integrations of rocMLIR.
cc: @sjw36 @krzysz00 @jerryyin

I am forming an opinion the coordinate transforms should just be a pretty constructors of affine maps and we should move our lowering/optimizations to be based on affine maps. The most important lowering related concern is vector length inference. I think we should be able to get this information by implementing a stride propogation mechanism for which have variety of number of tickets for problem key v2 reasons.

The only thing that stands in the way is padding. One thought it we can have a rock.implicit_pad op (ViewLikeOp) and somehow lower that to some metadata.

Im thinking of ( or similiar just a random thought cooked up just now; so dont get hung up on the interface and Im just trying to convey the idea)

f ( Vector<AffineMaps> , Vector<PaddingMetadata> ) -> Vector< Value > of upper strides.

This would allow us to make use of fusions either in the form of rock.transforms or linalg.pack + linalg.pad which we can lower to a combination of vectors of affine maps + rock.pad operations.

I d also think of carving a out a middle-end dialect for rock (that does not include things that are not needed for future possible integration).

[manupak]

Vector could also be a series of affine apply ops.

[krzysz00]

Re padding, the other thing we have going that I think IREE doesn't is that we speculatively index computations and (especially if my PR about this lands) stick nuw and nsw a bit more aggressively than they do