Add iterator for ReductionNode traversal and use range to indicate the region we would like to keep. Refactor the interaction between Pass/Tester/ReductionNode.
Now it'll be easier to add new traversal type and OpReducer
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for starting to look at this! Please fix the clang-tidy issues.
Can you also re-upload with full context?
mlir/include/mlir/Reducer/Pass | ||
---|---|---|
36 | Why return vector here? Can you just return module.getOps<OpType>() directly? | |
49 | Can you use ArrayRef here instead? | |
56 | nit: Spell out auto here. | |
58 | nit: Please drop all trivial braces in this commit. | |
72 | ||
mlir/include/mlir/Reducer/Passes/OpReducer.h | ||
29 | How is this different from the other OpReducer file? | |
mlir/include/mlir/Reducer/ReductionTreePass.h | ||
48–49 | Does this need to be on the pass instance? It looks like it gets reset every runOnOperation. (Same thing with the allocator, why not have it local to runOnOperation?) | |
mlir/tools/mlir-reduce/ReductionNode.cpp | ||
100 | nit: Use the llvm:: variants of all_of/remove_if/etc. | |
125 | Inner comments should use //. | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
24 | Can we just make the implementation here not templated instead? Moving to a .cpp seems like it would limit the ability for out-of-tree users to utilize this. | |
45 | Is something erasing these clones? |
mlir/include/mlir/Reducer/Pass | ||
---|---|---|
36 | Just inline module.getOps<OpType>(), removed getSpecificOps | |
56 | Sorry, I think this nit was required when getSepcificOps() is returning vector. I've changed to use module.getOps<OpType>(), do you think we still need to unroll it? it will be (result_pair<llvm::iterator_range<mlir::detail::op_iterator<mlir::FuncOp, mlir::Region::OpIterator>>>). | |
72 | It seems that we don't need this, I removed this function. If we need this information, I think it should be involved in pass information | |
mlir/include/mlir/Reducer/Passes/OpReducer.h | ||
29 | Sorry, the above file("mlir/include/mlir/Reducer/Pass") was added by accident. The refactor of OpReducer was supposed to be in the follow up CL. I've moved the changes into this CL | |
mlir/include/mlir/Reducer/ReductionTreePass.h | ||
48–49 | Moved to local vars in runOnOperation. |
Reduce the number of generating new variants and change to use llvm::ArrayRef while accessing variants vector.
mlir/include/mlir/Reducer/Passes/OpReducer.h | ||
---|---|---|
31 | Could you add a comment describing the member function? | |
34 | The previous approach here I see being generator like and towards having the same structure for all the reducers. So from the driver you'd have a common set of methods to call for each reducer. And so these now map to reduce and getNumTargetOps ? | |
39 | It seems with this change we lose the ability to specify number of variants is that correct? | |
mlir/include/mlir/Reducer/ReductionNode.h | ||
66 | Nit: Already in private scope | |
76 | I prefer public, protected and private ordering | |
mlir/include/mlir/Reducer/ReductionTreePass.h | ||
52 | Same re unneeded private | |
mlir/include/mlir/Reducer/Tester.h | ||
38 | I was thinking NotSure was like Maybe case, but it seems it is actually used to represent not tested yet, is that correct? Then perhaps Unexplored or Untested might be more intuitive | |
48 | Check is overloaded for me (probably due to CHECK), prefer something like Return the whether file in the given path is interesting. | |
mlir/lib/Reducer/Tester.cpp | ||
32 | Why are you printing to temporary file here? | |
43 | There is no bitcode here yet | |
mlir/tools/mlir-reduce/ReductionNode.cpp | ||
51 | maxElement? | |
56 | Elide braces for trivial if bodies | |
106 | Nit: remove this indentation, we don't have that style anywhere else here. | |
110 | So here you are testing if any of the variants are either interesting or not? (just filtering out notsure). | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
26 | Could TypeId be used here instead? |
Add more algorithm comments and fix some lints/erros based on review comments.
mlir/lib/Reducer/Tester.cpp | ||
---|---|---|
32 | This is used to let the test script exams the interestingness. | |
43 | Changed to IR. | |
mlir/tools/mlir-reduce/ReductionNode.cpp | ||
110 | In SinglePath approach, we would like to select the most reduced variant and keep traversing from that node. I added more comments in explaining the approach. | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
26 | We need a Op identifier but it seems that TypeID is bound to a specific value, right? If so, I think it may not be able to use in this case |
I think this looks good to go and we can always iterate
mlir/tools/mlir-reduce/ReductionNode.cpp | ||
---|---|---|
70 | Left over from debugging? | |
110 | Why +2? | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
26 | I was thinking one could do something like getOpReducer(TypeId opId) { if (opId == TypeID::get<ModuleOp>()) Perhaps I'm not following, but it seems it would give us this same structure (as we only use opType to dispatch to a particular version). But then again string comparison here is probably not on the hot path |
mlir/tools/mlir-reduce/ReductionNode.cpp | ||
---|---|---|
70 | Removed. lol | |
110 | vector::insert inserts an element before the given iterator and it returns the iterator points to the new element. Here we insert two split ranges so the one being split now is at it + 2 | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
26 | Yes, this one only be used once while pass initialization. OTOH, we will use command line to configure the reduction process(D100155), I will revisit this structure while we have more kinds of Reducer. |
mlir/include/mlir/Reducer/Passes/OpReducer.h | ||
---|---|---|
26 | Can you add comments for this method? and what rangeToKeep contains? | |
27 | nit: Drop the llvm:: here, ArrayRef is exported in the mlir namespace. | |
27 | Should this std::pair be ReductionNode::Range? | |
29 | Does this need to be templated? Can you pass in an OperationName to the constructor and use that for finding target ops instead? | |
41 | Is this supposed to be in the entire module? getOps only operates on one level of the IR (i.e. in the most directly nested region). | |
mlir/include/mlir/Reducer/ReductionTreePass.h | ||
59 | nit: Drop the llvm:: here, StringRef is exported in the MLIR namespace. | |
mlir/tools/mlir-reduce/ReductionTreePass.cpp | ||
22 | LLVM/MLIR style prefers using namespace instead. | |
26 | Inside of .cpp files, only classes should really be placed in namespaces. Functions should be marked as static and at the top level. | |
31 | If Reducer isn't templated, we wouldn't need to abort here. |
Fix linting erros.
@rriddle, about the OpReducer, I'm planing to have a registration structure for different type of Reducer in different projects. In this refactoring, I want to make the structure of graph traversal clear and extensible, I'll have another CL to address the Reducer soon. Do you think we can keep it for a short while?
Thanks
Chia-hung
Why return vector here? Can you just return module.getOps<OpType>() directly?