[PATCH] D74284: [mlir][VectorOps][EDSC] Add EDSC for VectorOps
Nicolas Vasilache via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 10 12:00:27 PST 2020
nicolasvasilache marked 5 inline comments as done.
nicolasvasilache added inline comments.
================
Comment at: mlir/lib/Dialect/VectorOps/EDSC/Builders.cpp:30
+ IndexingExprs{A.getExprs(), B.getExprs(), C.getExprs()},
+ ArrayRef<StringRef>{functional::map(toString, iteratorTypes)});
+}
----------------
mehdi_amini wrote:
> nicolasvasilache wrote:
> > One may think it is not great to materialize here but after spending too much time, I got to the following and still got compilation errors with issues converting to `const StringRef *`.
> > At this point I find it counterproductive and prefer the current form.
> >
> > ```
> > using IteratorTypeList = ArrayRef<IteratorType>;
> > class iterator_value_iterator final
> > : llvm::mapped_iterator<IteratorTypeList::iterator,
> > StringRef (*)(IteratorType)> {
> > public:
> > explicit iterator_value_iterator(IteratorTypeList::iterator it)
> > : llvm::mapped_iterator<IteratorTypeList::iterator,
> > StringRef (*)(IteratorType)>(
> > it, [](IteratorType iter) { return toString(iter); }) {}
> > StringRef operator*() const { return toString(*this->I); }
> > };
> >
> > llvm::iterator_range<iterator_value_iterator>
> > makeRange(ArrayRef<IteratorType> iteratorTypes) {
> > return llvm::make_range(iterator_value_iterator(iteratorTypes.begin()),
> > iterator_value_iterator(iteratorTypes.end()));
> > }
> >
> > Value mlir::edsc::ops::vector_contraction(
> > StructuredIndexed A, StructuredIndexed B, StructuredIndexed C,
> > ArrayRef<IteratorType> iteratorTypes) {
> > using IndexingExprs = ArrayRef<ArrayRef<AffineExpr>>;
> > auto range = makeRange(iteratorTypes);
> > return vector_contract(
> > A.getValue(), B.getValue(), C.getValue(),
> > IndexingExprs{A.getExprs(), B.getExprs(), C.getExprs()},
> > ArrayRef<StringRef>{range.begin(), range.end()});
> > }
> > ```
> What about materializing directly as an Array of StringAttr here instead of doing it in the builder?
> Right now you materialize here first and then the builder will trigger another call to functional::map()
That falls into the category of multiple attrs and having builders for multiple combinations of attrs vs underlying values.
Ideally I wouldn't fall in 2^n behavior here.
So either I'd go full attributes or full underlying values and reconstruct attributes, which is what I went for here.
Then orthogonally, the materialization is really a "proper API with ranges" issues on which I gave up in this revision.
If we were to care about optimization of this particular thing I'd prefer more effort into making ranges more usable.
================
Comment at: mlir/lib/IR/AffineMap.cpp:147
+ return inferFromExprList(exprsVector);
+}
+
----------------
mehdi_amini wrote:
> Using templates could avoid the temporary `exprsVector`, but I'm not sure it really matters...
Good enough, thanks!
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D74284/new/
https://reviews.llvm.org/D74284
More information about the llvm-commits
mailing list