This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by springerm on Mar 16 2023, 2:12 AM.

Details

Summary

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)

FlatLinearConstraints and FlatLinearValueConstraints 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).

Diff Detail

Event Timeline

springerm created this revision.Mar 16 2023, 2:12 AM
springerm requested review of this revision.Mar 16 2023, 2:12 AM
springerm updated this revision to Diff 506506.Mar 20 2023, 2:44 AM

rename: FlatConstraints -> FlatLinearConstraints

springerm edited the summary of this revision. (Show Details)Mar 20 2023, 2:49 AM
springerm edited the summary of this revision. (Show Details)Mar 22 2023, 1:14 AM
ftynse accepted this revision.Mar 22 2023, 1:55 AM

Mostly code motion, didn't go beyond the screening for obvious layering problems.

This revision is now accepted and ready to land.Mar 22 2023, 1:55 AM
dcaballe accepted this revision.Mar 22 2023, 10:39 AM
bondhugula accepted this revision.Mar 22 2023, 8:32 PM

This refactoring looks fine to me.

This revision was landed with ongoing or failed builds.Mar 23 2023, 1:39 AM
This revision was automatically updated to reflect the committed changes.
lattner added a subscriber: lattner.Apr 7 2023, 9:54 PM

This patch introduced a dependence of MLIR lib/Analysis on the Presburger logic. lib/Analysis is supposed to be mostly dependency free, can this be refactored another way?

This patch introduced a dependence of MLIR lib/Analysis on the Presburger logic. lib/Analysis is supposed to be mostly dependency free, can this be refactored another way?

The goal of this revision was to provide an API for IntegerPolyhedron with affine maps/expressions in MLIRAnalysis, without having to depend on any dialect, so that it can be used in op interfaces. This functionality used to be part of FlatAffineValueConstraints (in MLIRAffineDialect). It was extracted into FlatLinearConstraints (in MLIRAnalysis).

I had an alternative approach that put some functionality of FlatAffineValueConstraints into MLIRPresburger (https://reviews.llvm.org/D146029). This was not desirable because MLIRPresburger should not depend on constructs from MLIRIR. The only alternative I can think of is duplicating some functionality of FlatAffineValueConstraints in ValueBoundsOpInterface (which is where I needed the presburger functionality).

Note: MLIRAnalysis already depends on 8 interface build targets and (transitively) on MLIRIR. Looking at the directory structure, the presburger logic is in a subdirectory of Analysis, so this is basically MLIRAnalysis depending on another part of the analysis.

This patch introduced a dependence of MLIR lib/Analysis on the Presburger logic. lib/Analysis is supposed to be mostly dependency free, can this be refactored another way?

That's correct. lib/Analysis/ shouldn't depend on Presburger logic. The things in lib/Analysis that depend on Presburger logic have to go into either lib/Dialect/Affine/Analysis or somewhere else new. In fact, Presburger shouldn't have been in lib/Analysis/ to start with - I think it was kept there because some of Affine Analysis used to be there but moved out about a year ago. @springerm

This patch introduced a dependence of MLIR lib/Analysis on the Presburger logic. lib/Analysis is supposed to be mostly dependency free, can this be refactored another way?

That's correct. lib/Analysis/ shouldn't depend on Presburger logic. The things in lib/Analysis that depend on Presburger logic have to go into either lib/Dialect/Affine/Analysis or somewhere else new. In fact, Presburger shouldn't have been in lib/Analysis/ to start with - I think it was kept there because some of Affine Analysis used to be there but moved out about a year ago. @springerm

We could start a Utils directory directly under llvm-project/mlir and put it there. These utils would depend on MLIRIR though.

This patch introduced a dependence of MLIR lib/Analysis on the Presburger logic. lib/Analysis is supposed to be mostly dependency free, can this be refactored another way?

That's correct. lib/Analysis/ shouldn't depend on Presburger logic. The things in lib/Analysis that depend on Presburger logic have to go into either lib/Dialect/Affine/Analysis or somewhere else new. In fact, Presburger shouldn't have been in lib/Analysis/ to start with - I think it was kept there because some of Affine Analysis used to be there but moved out about a year ago. @springerm

We did want to move the Presburger directory to something like mlir/Math or mlir/ADT. If we decide to move it right now, I would be happy to send a patch for this change.

I'm less concerned with the name "Presburger" than with the dependence on this functionality. It would be fine to introduce an "AffineAnalysis" library or something similar, but this logic shouldn't be in the core MLIR analysis library IMO. It should be focused on more domain independent concepts like control flow and constant propagation which rely on core cross-domain abstractions in MLIR.

To say that another way, I don't think renaming Presburger to Math solves the problem. Analysis shouldn't depend on it regardless of what it is named.

To say that another way, I don't think renaming Presburger to Math solves the problem. Analysis shouldn't depend on it regardless of what it is named.

Sorry for being unclear, but what I meant was that the new location of Presburger would be mlir/Math/Presburger or mlir/ADT/Presburger. I raised this because it was mentioned that the Presburger library should not live in the Analysis directory. It's a self-contained library that focuses on providing mathematical functionality.