This commit rewrites most existing unittests involving FlatAffineConstraints to use the parsing utility. This helps to make the tests more understandable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
163 | Do you guys think that it makes sense to write these down as one constraint per line? | |
519 | This is not actually related to this patch, should I remove these changes? | |
574 | The parser can only introduce divisions if they actually show up in a constraint. Should I add a constraint that introduces these divisions or should we just drop that TODO? | |
mlir/unittests/Analysis/PresburgerSetTest.cpp | ||
376–379 | Alternatively, I could add a function that just takes a list of StringRefs which are all parsed and unioned. |
Thanks for the patch!
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
163 | Not sure, but at the very least it would be helpful to not break any single constraint across multiple lines. | |
519 | I guess ideally yes. Not sure how much it matters. | |
574 | I think you can use the parser with some dummy constraint here. We should be careful that it doesn't change the representation. (Adding a tighter constraint can change the returned numerator's constant term.) I think constraining each div to be greater than equal to zero would be good. Not sure if this works for nested divisions though; if there are any such cases we can leave them as is for now. | |
mlir/unittests/Analysis/PresburgerSetTest.cpp | ||
376–379 | Yeah, I think that would be helpful. |
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
574 | This does unfortunately not work as we want it to. The internal representation of fac looks as follows: Constraints (1 dims, 0 symbols, 2 locals), (4 constraints) (None None None const) 1 -10 0 4 >= 0 -1 10 0 5 >= 0 1 0 -10 100 >= 0 -1 0 10 -91 >= 0 But parsing, for example, "(x) : ((x + 4) floordiv 10 == 0, (x + 100) floordiv 10 == 0)" yields the following representation: Constraints (1 dims, 0 symbols, 2 locals), (6 constraints) (None None None const) 0 1 0 0 = 0 0 0 1 10 = 0 1 -10 0 4 >= 0 -1 10 0 5 >= 0 1 0 -10 0 >= 0 -1 0 10 9 >= 0 I'm not sure what changes the representation of the divisions, but this does break the test. Did I do something wrong or is this indeed a simplification the parser does? |
mlir/unittests/Analysis/PresburgerSetTest.cpp | ||
---|---|---|
376–379 | I added an example of such a helper function. Is this what you expected? |
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
574 | Yes, I think this is indeed something done by the parser. Maybe @Groverkss can confirm, but I don't think we have such simplifications anywhere else yet. I would just leave the division stuff out for now then. In the future we will implement such simplifications internally as well, and we would want to keep these tests as is so that we can test that functionality I guess. | |
mlir/unittests/Analysis/PresburgerSetTest.cpp | ||
376–379 | Yes, exactly. |
LGTM. I would wait for others to accept in case they have any remaining concerns.
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
574 | We do not have such simplifications. It's the parser that does these. I think it's better to not use the parser here. I don't think the parser will put the divisions in the order we want them to and it may become more confusing. You can drop the TODO according to me. |
LGTM, please fix the minor comment issues below.
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
182–188 | Please add back the comment above. // Same thing with some spurious extra dimensions equated to constants. | |
506–508 | These comments don't make sense anymore. I would replace the [0], [1] etc. by the actual constraints. | |
mlir/unittests/Analysis/PresburgerSetTest.cpp | ||
522–523 | This outdated comment can be removed now. |
Sorry: I had to revert because this broke the ASAN/UBSAN CI (see the trace in the revert commit message(
mlir/unittests/Analysis/AffineStructuresTest.cpp | ||
---|---|---|
222 | The mutated test case is too big to be computed with 64-bits, I believe that's why I initially chose this number of digits for this test case. I can't believe I manually checked the patch and still missed this |
Do you guys think that it makes sense to write these down as one constraint per line?