summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/Builders.cpp
diff options
context:
space:
mode:
authorNicolas Vasilache <ntv@google.com>2018-10-04 15:10:33 -0700
committerjpienaar <jpienaar@google.com>2019-03-29 13:23:05 -0700
commitb55b4076011419c8d8d8cac58c8fda7631067bb2 (patch)
tree9b5cefc99aa0f0d7a93a443d501a4b67a57a2439 /mlir/lib/IR/Builders.cpp
parent5b8017db187c7ef5456cccaa514e8684710d2103 (diff)
downloadbcm5719-llvm-b55b4076011419c8d8d8cac58c8fda7631067bb2.tar.gz
bcm5719-llvm-b55b4076011419c8d8d8cac58c8fda7631067bb2.zip
[RFC][MLIR] Use AffineExprRef in place of AffineExpr* in IR
This CL starts by replacing AffineExpr* with value-type AffineExprRef in a few places in the IR. By a domino effect that is pretty telling of the inconsistencies in the codebase, const is removed where it makes sense. The rationale is that the decision was concisously made that unique'd types have pointer semantics without const specifier. This is fine but we should be consistent. In the end, the only logical invariant is that there should never be such a thing as a const AffineExpr*, const AffineMap* or const IntegerSet* in our codebase. This CL takes a number of shortcuts to killing const with fire, in particular forcing const AffineExprRef to return the underlying non-const AffineExpr*. This will be removed once AffineExpr* has disappeared in containers but for now such shortcuts allow a bit of sanity in this long quest for cleanups. The **only** places where const AffineExpr*, const AffineMap* or const IntegerSet* may still appear is by transitive needs from containers, comparison operators etc. There is still one major thing remaining here: figure out why cast/dyn_cast return me a const AffineXXX*, which in turn requires a bunch of ugly const_casts. I suspect this is due to the classof taking const AffineXXXExpr*. I wonder whether this is a side effect of 1., if it is coming from llvm itself (I'd doubt it) or something else (clattner@?) In light of this, the whole discussion about const makes total sense to me now and I would systematically apply the rule that in the end, we should never have any const XXX in our codebase for unique'd types (assuming we can remove them all in containers and no additional constness constraint is added on us from the outside world). PiperOrigin-RevId: 215811554
Diffstat (limited to 'mlir/lib/IR/Builders.cpp')
-rw-r--r--mlir/lib/IR/Builders.cpp10
1 files changed, 5 insertions, 5 deletions
diff --git a/mlir/lib/IR/Builders.cpp b/mlir/lib/IR/Builders.cpp
index ad52300f84b..8ca0fe8318f 100644
--- a/mlir/lib/IR/Builders.cpp
+++ b/mlir/lib/IR/Builders.cpp
@@ -150,8 +150,8 @@ FunctionAttr *Builder::getFunctionAttr(const Function *value) {
//===----------------------------------------------------------------------===//
AffineMap *Builder::getAffineMap(unsigned dimCount, unsigned symbolCount,
- ArrayRef<AffineExpr *> results,
- ArrayRef<AffineExpr *> rangeSizes) {
+ ArrayRef<AffineExprRef> results,
+ ArrayRef<AffineExprRef> rangeSizes) {
return AffineMap::get(dimCount, symbolCount, results, rangeSizes, context);
}
@@ -224,7 +224,7 @@ AffineExprRef Builder::getCeilDivExpr(AffineExprRef lhs, uint64_t rhs) {
}
IntegerSet *Builder::getIntegerSet(unsigned dimCount, unsigned symbolCount,
- ArrayRef<AffineExpr *> constraints,
+ ArrayRef<AffineExprRef> constraints,
ArrayRef<bool> isEq) {
return IntegerSet::get(dimCount, symbolCount, constraints, isEq, context);
}
@@ -251,9 +251,9 @@ AffineMap *Builder::getSingleDimShiftAffineMap(int64_t shift) {
}
AffineMap *Builder::getShiftedAffineMap(AffineMap *map, int64_t shift) {
- SmallVector<AffineExpr *, 4> shiftedResults;
+ SmallVector<AffineExprRef, 4> shiftedResults;
shiftedResults.reserve(map->getNumResults());
- for (auto *resultExpr : map->getResults()) {
+ for (auto resultExpr : map->getResults()) {
shiftedResults.push_back(getAddExpr(resultExpr, shift));
}
return AffineMap::get(map->getNumDims(), map->getNumSymbols(), shiftedResults,
OpenPOWER on IntegriCloud