This is an archive of the discontinued LLVM Phabricator instance.

[mlir][analysis][NFC] Move functions from FlatAffineValueConstraints to IntegerPolyhedron
AbandonedPublic

Authored by springerm on Mar 14 2023, 3:25 AM.

Details

Summary

Move addBound overloads with AffineMaps, getSliceBounds and getLowerAndUpperBound from FlatAffineValueConstraints to IntegerPolyhedron. This functionality can now be used without depending on the Affine dialect.

This is in preparation of D145681, which adds ValueBoundsOpInterface to mlir/Interfaces.

Depends On: D145935

Diff Detail

Event Timeline

springerm created this revision.Mar 14 2023, 3:25 AM
springerm requested review of this revision.Mar 14 2023, 3:25 AM
Groverkss requested changes to this revision.Mar 14 2023, 3:57 AM

This introduces a dependency of the Presburger library on IR constructs like AffineMap, and IntegerSet, which was discussed before as a dependency we do not want to put. This is the reason FlatAffineConstraints contains these functions, and they were not moved.

This revision now requires changes to proceed.Mar 14 2023, 3:57 AM

The Presburger equivalent of an AffineMap is presburger::MultiAffineFunction (aka MAF). Ideally, a conversion between AffineMap to MAF should be added, and these methods should use MAF instead.

This introduces a dependency of the Presburger library on IR constructs like AffineMap, and IntegerSet, which was discussed before as a dependency we do not want to put. This is the reason FlatAffineConstraints contains these functions, and they were not moved.

How about adding another class in the hierarchy:

IntegerRelation
   ^
   |
IntegerPolyhedron
   ^
   |
FlatAffineConstraints (or another name)
   ^
   |
FlatAffineValueConstraints

FlatAffineConstraints would be in in mlir/Analysis. I can be in a build target/directory different from Presburger.

Context: We have a use case for FlatAffineValueConstraints in an op interface (mlir/Interfaces). Build targets in mlir/Interfaces cannot depend on any dialect, so we cannot use FlatAffineValueConstraints.
Discussion on Discourse: https://discourse.llvm.org/t/rfc-valueboundsopinterface-compute-bounds-of-index-values-dyn-dim-sizes/69174

The Presburger equivalent of an AffineMap is presburger::MultiAffineFunction (aka MAF). Ideally, a conversion between AffineMap to MAF should be added, and these methods should use MAF instead.

If AffineMap and MultiAffineFunction are equivalent, why do we have MultiAffineFunction? (AffineExpr and AffineMap are in the IR build target, so they can be used without depending on any dialect.)

This introduces a dependency of the Presburger library on IR constructs like AffineMap, and IntegerSet, which was discussed before as a dependency we do not want to put. This is the reason FlatAffineConstraints contains these functions, and they were not moved.

How about adding another class in the hierarchy:

Basically, I'm trying to see if we can extract a subset of FlatAffineValueConstraints that does not depend on any affine ops and put it in mlir/Analysis. A better name would be FlatValueConstraints. It would not have functions such as addAffineIfOpDomain etc. FlatAffineValueConstraints (as a subclass) would add provide those functions. Would this work?

The Presburger equivalent of an AffineMap is presburger::MultiAffineFunction (aka MAF). Ideally, a conversion between AffineMap to MAF should be added, and these methods should use MAF instead.

If AffineMap and MultiAffineFunction are equivalent, why do we have MultiAffineFunction? (AffineExpr and AffineMap are in the IR build target, so they can be used without depending on any dialect.)

Sorry for the confusion, when I said they are "equivalent", I meant they represent the same mathematical function. Their storage is very different. MAF stores a flattened version of the function, which is useful for analysis, while AffineMap, and AffineExpr store an AST representation of the function.

This introduces a dependency of the Presburger library on IR constructs like AffineMap, and IntegerSet, which was discussed before as a dependency we do not want to put. This is the reason FlatAffineConstraints contains these functions, and they were not moved.

How about adding another class in the hierarchy:

IntegerRelation
   ^
   |
IntegerPolyhedron
   ^
   |
FlatAffineConstraints (or another name)
   ^
   |
FlatAffineValueConstraints

FlatAffineConstraints would be in in mlir/Analysis. I can be in a build target/directory different from Presburger.

Context: We have a use case for FlatAffineValueConstraints in an op interface (mlir/Interfaces). Build targets in mlir/Interfaces cannot depend on any dialect, so we cannot use FlatAffineValueConstraints.
Discussion on Discourse: https://discourse.llvm.org/t/rfc-valueboundsopinterface-compute-bounds-of-index-values-dyn-dim-sizes/69174

I would personally prefer the conversion to MAF and using MAF for adding bounds solution and would also be up for helping by sending patches for it.

For the changing hierarchy solution, I think it is fine, but I would wait to see what @ftynse and @bondhugula think.

springerm abandoned this revision.Mar 16 2023, 2:14 AM

Splitting FlatAffineValueConstraints: D146201