This is an archive of the discontinued LLVM Phabricator instance.

Refactor Reduction Tree Pass
ClosedPublic

Authored by msifontes on Aug 8 2020, 4:11 PM.

Details

Summary

Refactor the way the reduction tree pass works in the MLIR Reduce tool by introducing a set of utilities that facilitate the implementation of new Reducer classes to be used in the passes.

This will allow for the fast implementation of general transformations to operate on all mlir modules as well as custom transformations for different dialects.

These utilities allow for the implementation of Reducer classes by simply defining a method that indexes the operations/blocks/regions to be transformed and a method to perform the deletion or transformation based on the indexes.

Create the transformSpace class member in the ReductionNode class to keep track of the indexes that have already been transformed or deleted at the current level.

Delete the FunctionReducer class and replace it with the OpReducer class to reflect the use of the new API while performing the same transformation and allowing the instantiation of a reduction pass for different types of operations at the module's highest hierarchichal level.

Modify the SinglePath Traversal method to reflect the use of the new API.

Diff Detail

Event Timeline

msifontes created this revision.Aug 8 2020, 4:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2020, 4:11 PM
msifontes requested review of this revision.Aug 8 2020, 4:11 PM
msifontes edited the summary of this revision. (Show Details)Aug 8 2020, 4:21 PM
msifontes updated this revision to Diff 284159.Aug 8 2020, 6:14 PM

Fix indexing bug in createTransformedVariants().

msifontes updated this revision to Diff 284533.Aug 10 2020, 5:11 PM

Merge createTransformedVariants and createErasedVariants utilities into single createVariants utility.

msifontes updated this revision to Diff 284747.Aug 11 2020, 8:30 AM

NFC: clang-format

jpienaar added inline comments.Aug 11 2020, 9:51 AM
mlir/tools/mlir-reduce/Passes/OpReducer.cpp
31 ↗(On Diff #284747)

So seems like template is only used for getOps really. So you could have your implementation have functionref Module -> iterator_range<OpIterator> filter function and then avoid templating inside here. You could still have the simple templated top class, but then the instantiated one & implementation could just call the filter function and so in you cpp file you'd have no templates.

68 ↗(On Diff #284747)

This seems less ideal than having the above in a header as I think this restricts you to only use these ops.

msifontes marked 2 inline comments as done.

Apply Requested changes

  • Modify OpReducer class to use PImpl idiom.
  • Modify Reduction Tree Utilities to use llvm::function_ref instead of std::function

NFC: Formatting changes

Merge confilcts in working tree.

Change mlir-reduce.cpp to use new OpReducer

Remove unused headers in OpReducer.h

Modify the reduction node transform space to use a bool vector with the transformed indices marked as true.

msifontes updated this revision to Diff 286398.Aug 18 2020, 2:15 PM

Fix clang-format error

jpienaar accepted this revision.Aug 20 2020, 4:58 PM

Nice thanks, LG with comments addressed

mlir/include/mlir/Reducer/Passes/OpReducer.h
38

Why not const Tester& ? Is null allowed?

42

Could you expand to document what transform arg does/how it will be used?

52

These would all be of OpType?

54

Lets make this OpType as refers to class

mlir/include/mlir/Reducer/ReductionTreePass.h
101 ↗(On Diff #286398)

Could we change 1 and 2 (below) to something more informative?

133 ↗(On Diff #286398)

Same here

mlir/include/mlir/Reducer/ReductionTreeUtils.h
31 ↗(On Diff #286398)

Mmm, if these are all static, why not just have these in a namespace rather than class?

35 ↗(On Diff #286398)

processNode is too general as a utility function name. Lets find something more descriptive.

mlir/tools/mlir-reduce/Passes/OpReducer.cpp
1 ↗(On Diff #286398)

Line update?

mlir/tools/mlir-reduce/ReductionTreeUtils.cpp
35 ↗(On Diff #286398)

Why not just range based for?

69 ↗(On Diff #286398)

Should this be wrapped in LLVM_DEBUG too?

122 ↗(On Diff #286398)

Where is this used?

This revision is now accepted and ready to land.Aug 20 2020, 4:58 PM
msifontes updated this revision to Diff 286950.Aug 20 2020, 9:34 PM
msifontes marked 12 inline comments as done.

Apply requested changes

  • Use constant Tester reference throughout.
  • Modify debugging messages to explain how the variants are being created.
  • Change the ReductionTreeUtils class to be a namespace.
  • Replace processNode method name with updateSmallestNode.
This revision was automatically updated to reflect the committed changes.