This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Presburger] Add Identifier class to store identifiers and their type
ClosedPublic

Authored by Groverkss on Mar 26 2023, 5:18 AM.

Details

Summary

This patch adds a new class Identifier to store identifiers in PresburgerSpace
and their types.

Identifiers were added earlier and were stored as a void pointer, and their type
in the form of mlir::TypeId in PresburgerSpace. To get an identifier, a user of
PresburgerSpace needed to know the type of identifiers. This was a problem for
users of PresburgerSpace like IntegerRelation, which want to work on
identifiers without knowing their type.

The Identifier class allows users like IntegerRelation to work on identifiers
without knowing their type, and also exposes an easier way to work with
Identifiers.

Diff Detail

Event Timeline

Groverkss created this revision.Mar 26 2023, 5:18 AM
Groverkss requested review of this revision.Mar 26 2023, 5:18 AM
arjunp added inline comments.May 12 2023, 6:14 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
31–35

I think we need much more documentation to explain all this to someone who doesn't already know what it is.

155–159
158

"actually same variable" doesn't seem to make sense within the context of PresburgerSpace.

Can you instead say something like, the user can identify each variable in the space as corresponding to some Identifier, and then explain clearly how and where these identifiers are used, if at all. This should make sense when taken together with the identifier documentation

mlir/unittests/Analysis/Presburger/PresburgerSpaceTest.cpp
90–93

why was the API changed here?

I'd requesting expanding commit summary to include sufficient rationale and summary of the change, and what it enables.

mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
31–35

I agree. Examples will also help here.

84–86

What's this?

Groverkss updated this revision to Diff 523013.May 17 2023, 5:39 AM
Groverkss marked 6 inline comments as done.
  • Address comments
Groverkss edited the summary of this revision. (Show Details)May 17 2023, 6:00 AM
Groverkss added inline comments.
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
84–86

oops, removed.

mlir/unittests/Analysis/Presburger/PresburgerSpaceTest.cpp
90–93

To make it consistent with how we do this through Presburger Library. We don't have setters; instead, we use get as a reference and set it that way.

arjunp added inline comments.May 17 2023, 6:20 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
31

or replace with some other examples you have in mind

33

two variables in what? same set? different sets with same space? different space?

39

this notation is unclear. can you write some kind of example statement S0: A[i][j] = 0 instead

49

The discussion here seems to imply that the names i and j are somehow relevant here. can your clarify this

56
58
60

not clear what "always unique" means. can you just say it's treated as no attachment and then describe the behaviour of such variables

Groverkss updated this revision to Diff 541521.Jul 18 2023, 7:26 AM
Groverkss marked 7 inline comments as done.
  • Address more comments
  • Address mroe comments
  • isEqual type assert
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
33

I don't think it matters? They can be used for two different variables in anything.

arjunp added inline comments.Jul 18 2023, 8:27 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
41

might be clearer if you use j and k instead of two js

46

I can't understand this syntax. Are they two spaces? Above it says "a PresburgerSpace"

48
56

Documentation is unclear on whether different variables can have different types of objects attached

56–58

"previous example" is unclear whether it is referring to the same code example, or the actual previous example where you attached Values to identifiers. I assume you mean the former, if so can you write it out explicitly.

61
66

Why are the impls in the header?

81

Can you write a longer assert message explaining what's happening

89

Same pointer with different types can only happen due to an internal error in the class, right? So why are we telling the user about that in the API comment?

158
159
286–287

Please clarify what happens with null ids

289–290
303–304

What is this? Please document.

Groverkss updated this revision to Diff 541604.Jul 18 2023, 9:44 AM
Groverkss marked 14 inline comments as done.
  • Address more comments
Groverkss added inline comments.Jul 18 2023, 9:49 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
56

That's a user class detail? I don't see why that should be in the documentation of Identifier.

56–58

I feel that paragraph was unnecessary. I removed that paragraph, as it just caused problems.

66

Templated methods need to be implemented in the header file.

89

I want to allow Identifiers in the same object to be of different types, so I want to keep this in the documentation.

286–287

Currently, null ids are treated as not equal and the check fails. I added a line that specifies what happens when identifiers are not being used. I will specify the null ids behavior more in another patch. But for now, they are treated as not equal.

303–304

Sorry, accidentally committed this.

arjunp added inline comments.Jul 18 2023, 10:24 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
56

What do you mean user class detail? I just want you to write here that the type of object attached can be different for different variables in the space.

66

I would put the remaining methods implementations in the cpp to reduce compile time, not sure if there are any other considerations in favour of keeping them in the header.

89

My bad, I was assuming the same pointer can't have different types right, and that the assert will only fail if we somehow messed up with storing pointers. But actually we could have released the pointer and been allocated another one with a different type. Just add another sentence explaining why this could happen (only because of realloc of a different type of object to the same pointer). This seems like a weird failure case, I think we should make clear what the behaviour of identifier is with deallocating/reallocating pointers (because it affects things like this).

260–264

kind != VarKind::Local

291

Can you write a sentence explaining why this overload is useful

mlir/lib/Analysis/Presburger/PresburgerSpace.cpp
225
226–229

use the getIds function you defined?

234–246

Is the notion of a space "using" or "not using" identifiers explained in any of the class-level docs?

236

personally I prefer !=

238–239

they also have to be compatible right

261

like above, this check needs to be first I believe

280

this can just be a free function

282

i < e

282

Use getIds and range-based for?

284

should we add a contextual (explicit) conversion to bool?

Groverkss updated this revision to Diff 551701.Aug 18 2023, 9:15 PM
Groverkss marked 14 inline comments as done.
  • Address comments
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
56

I meant that PresburgerSpace allows for both, but the using class (say IntegerRelation) decides if the objects attached need to be of the same type or not. Anyway, I added the line you wanted.

66

Most of them are one-linears :P I moved isEqual, print and dump in the implementation file.

89

We allow storing anything that has llvm::PointerLikeTypeTraits. I could define PointerLikeTypeTraits for a custom integer and store things there, so there are more cases where this could happen. I made the behavior of equality more clear in the Identifier definition instead.

As long as the equality behavior is clear and we are getting a descriptive assert, I think we don't need to write the realloc sentence.

mlir/lib/Analysis/Presburger/PresburgerSpace.cpp
234–246

Yes, last paragraph in PresburgerSpace documentation.

238–239

Identifiers being equal automatically implies compatibility, added a comment about this.

280

Sure, but I don't see why I would need this as a free function instead. I don't think any other function would need printing and it's cleaner to write with a lambda capture.

284

I prefer explicit checking.

Groverkss marked an inline comment as done.Aug 18 2023, 9:15 PM

Please add some tests for convertVarKind. Other than that, some last nits below:

mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
49

pls change "Are different" to something like "correspond to different SSA values in the program"

56

Yes, so PresburgerSpace should mention that it allows both.

56–57

similarly here -- check they correspond to same variable in the program

58
60–61
62
63
64
70

consider writing this constraint in the class doc instead?

156
286–287
Groverkss updated this revision to Diff 551988.Aug 21 2023, 4:55 AM
Groverkss marked 11 inline comments as done.
  • Address comments
  • Address comments
  • Fix convertVarKind test
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
70

I think of this is a method detail rather than a class detail. The idea of identifier is still the same, this is just how we implement it. I would prefer it to be here.

286–287

"in both spaces have the same identifiers" does not make it clear that they need to be at the same position as well.

Please add tests for the other two cases (from and to locals). I really find these kinds of things finicky, as we just saw, so I think it's better to test them a bit exhaustively.

mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
70

But this is a constraint of how the class can be used, right?

286–287

ok can you write "same identifiers in the same positions" then? I find the current order confusing.

Groverkss updated this revision to Diff 555627.Sep 3 2023, 3:53 AM
Groverkss marked 2 inline comments as done.
  • Address comments
Groverkss added inline comments.Sep 3 2023, 3:54 AM
mlir/include/mlir/Analysis/Presburger/PresburgerSpace.h
70

Not really? It's just this specific constructor uses it to build an identifier, which is why it's in the constructor documentation. To me, the identifier has no relation with this llvm::PointerLikeTypeTraits. It's just the constructor does. Nothing else in the class cares about it or should ever care about it.

It's not a constraint on the class. You can easily add a constructor that takes a void* pointer and a type and it should be fine as well.

arjunp accepted this revision.Sep 4 2023, 4:30 AM

The class currently uses type traits right? getValue currently uses llvm::PointerLikeTypeTraits<T>::getFromVoidPointer(value);. Please mention the constraint in the class doc before landing.

This revision is now accepted and ready to land.Sep 4 2023, 4:30 AM
Groverkss updated this revision to Diff 555813.Sep 4 2023, 11:46 PM
  • Documentation
Groverkss updated this revision to Diff 555815.Sep 5 2023, 12:13 AM
  • Fix tests
  • Fix warning in unittests
This revision was landed with ongoing or failed builds.Sep 5 2023, 12:16 AM
This revision was automatically updated to reflect the committed changes.