- User Since
- Feb 2 2017, 2:24 AM (190 w, 18 h)
Tue, Sep 22
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 ?
Mon, Sep 21
Address review comments.
Additional changes and builders.
Fri, Sep 18
Thanks for discussing, some comments.
Putting a blocker to get some discussion here.
Drop extra dialect name form printing.
Spin a custom parser as declarative assembly extension is blocked for now.
Thu, Sep 17
Fix incorrect OpBuilder state with an InsertionGuard.
Better building of block.
Tmp OpBuilder creation.
Thanks @dcaballe !
Finishing the impl and adding unit tests.
Wed, Sep 16
Thanks @ezhulenev !
Thanks for your reviews, I have something better planned so I am abandonning this one.
Tue, Sep 15
Mon, Sep 14
Landed as e6f2f17f05a1248b069ba830c4afffd61ee2f297
Fri, Sep 11
Fix bug, add helpers and a roundtrip test.
Thu, Sep 10
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.
Wed, Sep 9
The alternative would be that I copy the guts of the matchAndRewrite method of LinalgBaseTilingPattern
Tue, Sep 8
@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 much for updating this older piece!
First this is not an issue but a feature of C++.
Builders would have the same behavior as explained in the discourse post.
Mon, Sep 7
Looks good, thanks @limo1996 !
Fri, Sep 4
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 )
Thu, Sep 3
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.
Wed, Sep 2
Great, thank you @limo1996 !
Tue, Sep 1
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.
Aug 19 2020
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?