[mlir][Analysis][NFC] Split FlatAffineValueConstraints into multiple classes

The new class hierarchy is as follows:

* `IntegerRelation` (no change)
* `IntegerPolyhedron` (no change)
* `FlatLinearConstraints`: provides an AffineExpr-based API
* `FlatLinearValueConstraints`: stores an additional mapping of non-local vars to SSA values
* `FlatAffineValueConstraints`: provides additional helper functions for Affine dialect ops
* `FlatAffineRelation` (no change)

`FlatConstraints` and `FlatValueConstraints` are moved from `MLIRAffineAnalysis` to `MLIRAnalysis` and can be used without depending on the Affine dialect.

This change is in preparation of D145681, which adds an MLIR interface that depends on `FlatConstraints` (and cannot depend on the Affine dialect or any other dialect).

Differential Revision: https://reviews.llvm.org/D146201

1 files changed, 3 insertions, 3 deletions

diff --git a/mlir/docs/Rationale/UsageOfConst.md b/mlir/docs/Rationale/UsageOfConst.md
index 102b948a0eac..7a54a4e6de7f 100644
--- a/mlir/docs/Rationale/UsageOfConst.md
+++ b/mlir/docs/Rationale/UsageOfConst.md
@@ -235,9 +235,9 @@ if (auto *dimOp = inst->dyn_cast<DimOp>()) {
 It is much better to eliminate them entirely, and just pass around `DimOp`
 directly. For example, instead of:
 
-```C++
+```c++
 LogicalResult mlir::getIndexSet(MutableArrayRef<OpPointer<AffineForOp>> forOps,
-                                FlatAffineConstraints *domain) {
+                                FlatAffineValueConstraints *domain) {
 
 ```
 
@@ -245,7 +245,7 @@ It is a lot nicer to just have:
 
 ```c++
 LogicalResult mlir::getIndexSet(MutableArrayRef<AffineForOp> forOps,
-                                FlatAffineConstraints *domain) {
+                                FlatAffineValueConstraints *domain) {
 ```
 
 Particularly since all of the `FooOp` classes are already semantically a smart