What does it mean for a linalg op to take unranked memref?
In particular, a linalg op has indexing_maps. of fixed rank.
How would that work with unranked stuff ?

Address review comments.

Additional changes and builders.

Thanks for discussing, some comments.

Putting a blocker to get some discussion here.

Drop extra dialect name form printing.

DCE

Spin a custom parser as declarative assembly extension is blocked for now.

Update

InsertionGuard.

Fix incorrect OpBuilder state with an InsertionGuard.

Better building of block.

Address review

Tmp OpBuilder creation.

Thanks @dcaballe !

Finishing the impl and adding unit tests.

Thanks @ezhulenev !

Thanks for your reviews, I have something better planned so I am abandonning this one.

Looks good!

Landed as e6f2f17f05a1248b069ba830c4afffd61ee2f297

Fix test

Fix bug, add helpers and a roundtrip test.

Format

Address review.

Thanks!

Thanks!

Thanks!

I am not concerned. by having many ops as long as the underlying mechanisms are shared.
Of course, I agree that more core work is needed to get new op definitions to be just the 4 lines in .tc.
This is just a bit of tablegen + macro away so I am not worried that a future CL will make things more automatic.

@burmako ah my apologies, I thought you wanted a linalg op that would operate on memref<vector>.

Could you please describe the use case a bit?
Should this be an abstract base that never deletes and a default derived that deletes + other derived that do X and delete?

Thanks !

Thanks much for updating this older piece!

yes :) https://reviews.llvm.org/D87273

First this is not an issue but a feature of C++.
Builders would have the same behavior as explained in the discourse post.

Looks good, thanks @limo1996 !

Update.

Thanks for tracking and fixing the perf bug Aart!
Maybe this also influences how aggressive we need to be in splitting in the codegen strategy to get to peak.
Will also be interesting to see the effects on mobile (cc @asaadaldien )

Note I am also making some changes to the scalar path for other correctness purposes.
There may be something interesting to do down the line.

Great, thank you @limo1996 !

Thanks @bkramer !

Thanks for extending the SuperVectorizer !

Thanks for this @dcaballe, I'm. a big fan of more composable APIs and less blackbox heuristics.

This is not how I was imagining convolution to be lowered in a first stab.
I was expecting 1. taking subviews, 2. either using reshape or extending subviews to allow it to be rank-reducing, 3. rewrite as a linalg.matmul and reuse the existing vectorization patterns.

I was under the impression that you were implementing the more general case but indeed not.
Then please just make sure the writes behave properly too, thanks!

There are a few different places where patterns apply where we make the test that the permutation map is identity and that the rest is not yet supported.
Please update such places too and add tests to extend support more generally.

If it wants to subsume vector.type_cast, how does this interact with n-D vectors for n>1?