Use an MLIRContext declared in a single place in the parsePoly function that almost all Presburger unit tests use for parsing sets. This function is only used in tests.
This saves us from having to declare and pass a new MLIRContext in every test.
Paths
| Differential D119251
[MLIR][Presburger] unittests: use an MLIRContext declared in parsePoly ClosedPublic Authored by arjunp on Feb 8 2022, 7:58 AM.
Details Summary Use an MLIRContext declared in a single place in the parsePoly function that almost all Presburger unit tests use for parsing sets. This function is only used in tests. This saves us from having to declare and pass a new MLIRContext in every test.
Diff Detail
Event TimelineHerald added subscribers: sdasgup3, wenzhicui, wrengr and 20 others. · View Herald TranscriptFeb 8 2022, 7:58 AM Comment Actions This LGTM, but I would wait for @bondhugula to review in case he has any concerns with unit tests having a static MLIRContext. Comment Actions Please don't leave the commit summary empty in such cases -- please always add a line as to the rationale. This revision now requires changes to proceed.Feb 18 2022, 5:04 PM bondhugula added inline comments.
arjunp removed a child revision: D120127: [MLIR][Presburger] Introduce MaybeOptimum type to represent computed optima.Feb 19 2022, 12:05 PM Comment Actions Have you considered using a fixture and have your context dependent functions be methods on it? https://github.com/google/googletest/blob/main/docs/primer.md#test-fixtures-using-the-same-data-configuration-for-multiple-tests-same-data-multiple-tests Comment Actions Actually, I realised there is no reason for this to be static. I don't think we face any issue if different IntegerPolyhedrons even in the same test are constructed from different MLIRContexts. Is the problem only with making this static? (Also, what is the problem with that?) The fixture could work, but I see some downside with each possible approach: a) defining one single test fixture with parsePoly as member function and an MLIRContext member in the Utils.h -- this has the disadvantage that all test groups like IntegerPolyhedronTest, PresburgerSetTest, will have to be changed to the same name. b) defining one single fixture as above and public inheriting from it with different names. I think this might work but it's a bit weird. c) copy pasting the same parsePoly/MLIRContext fixture in each test file -- too much code duplication. Comment Actions
MLIRContext is a pretty heavy class -- won't its default ctor not entail a lot of overhead? See how many DenseMap's, unique ptrs, and thread pool related stuff MLIRContextImpl has. Comment Actions On my machine (-O0 -g -ftrapv). Runtime before patch (MLIRContext for each test): ~0.345s It seems to be a matter of +-10% performance. mehdi_amini added inline comments.
arjunp retitled this revision from [MLIR][Presburger] unittests: use a single static MLIRContext in parsePoly to [MLIR][Presburger] unittests: use an MLIRContext declared in parsePoly.Feb 21 2022, 11:48 AM This revision is now accepted and ready to land.Feb 23 2022, 6:07 AM This revision was landed with ongoing or failed builds.Feb 23 2022, 7:07 AM Closed by commit rG4b86d55997cf: [MLIR][Presburger] unittests: use an MLIRContext declared in parsePoly (authored by arjunp). · Explain Why This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 410818 mlir/unittests/Analysis/Presburger/IntegerPolyhedronTest.cpp
mlir/unittests/Analysis/Presburger/PWMAFunctionTest.cpp
mlir/unittests/Analysis/Presburger/PresburgerSetTest.cpp
mlir/unittests/Analysis/Presburger/SimplexTest.cpp
mlir/unittests/Analysis/Presburger/Utils.h
|
Switch to static MLIRContext *looks* fine to me. I don't have specific insights. @mehdi_amini, any comments?