- User Since
- Feb 26 2020, 10:38 PM (117 w, 1 d)
Oct 29 2021
Oct 19 2021
Add more checks to OperationParser::resolveSSAUse to handle the misuse of the feature.
Oct 18 2021
@ftynse I've addressed your comments.
Addressed review comments
@bondhugula I've addressed your comments, please take a look one more time.
Addressed review comments
Oct 15 2021
Updated according to review remarks
I've redone the change. Now it doesn't touch the ODS generation logic,
instead I've used Custom Directives in assembly format to implement the desired behavior.
The only change in the core part - relaxed check in the OperationParser.
Oct 13 2021
Oct 12 2021
Rebased to re-run pre-commit CI
Applied review remark and reverted unnecessary format changes
Oct 11 2021
I've excluded questionable part (non-const references support) from the patch.
Could you please take a look one more time?
Oct 1 2021
Sep 20 2021
Fix llvm_canonicalize_cmake_booleans usage
@akuegel Yes, I'm currently investigating them.
Rebased and extend NOTE/TODO comment
Sep 19 2021
Sep 3 2021
Aug 26 2021
Aug 23 2021
@rriddle I've fixed your remarks
Fix review remarks
Fixed review remarks
@bondhugula I've fixed your remarks.
Applied review remarks.
Aug 21 2021
Aug 20 2021
Aug 19 2021
Aug 6 2021
@rriddle I've applied your suggestions.
Apply review remarks
Aug 5 2021
Aug 4 2021
Aug 3 2021
Or in other words, current implementation doesn't allow to attach the same interface implementation to several objects from one dialect. And it doesn't matter if it is a single interface model for all objects or it is different model classes.
Aug 2 2021
Jul 28 2021
Actually it is shown in the test) We decompose virtual index permutation and strided form:
@nicolasvasilache I've started a discussion on discourse with this topic - https://llvm.discourse.group/t/rfc-memreftype-affine-maps-list-vs-single-item/3968
The thing is - MemRefType API allows to use lists of affine maps. But in various places there are assumption, that it contains single item (or it is empty). And sometimes those assumption is not even checked and just the first/last item is used without any check/assertion. IMHO, this makes the code base fragile.
@ftynse Thanks for clarification! Actually in our internal project we use decomposed list of affine maps exactly as in your example (separate virtual indexing permutation and strided form to get physical indexing). At least this approach doesn't contradict original MemRef design.
I have a question about affine maps list in MemRef type in general. Just this is the second place on my memory, where only the first element of the list is used. Which brings a question, why MemRef uses list of affine maps and not a single affine map? I was under impression, that the list allows to store a composition of affine maps to make it simpler for some cases. Is this true or its wrong interpretation?
Jul 27 2021
Jul 26 2021
Jul 17 2021
@rriddle I've fixed your remarks.
Fixed review remarks.
Jul 7 2021
Jun 21 2021
Jun 18 2021
@lattner Sorry, my comment about Canonicalization pass was wrong and confusing (removed it).
Removed confusing comment about Canonicalization pass.
Jun 17 2021
Jun 15 2021
May 5 2021
Apr 2 2021
Why it is located in MLIRStandardOpsTransforms, while operating in MemRef dialect? I would expect it to be a part of MLIRMemRefTransforms.
Mar 26 2021
Added a test for the issue