Add a helper class UnregisteredOp for the unregistered ops to get the
similar ability as registered ops while using some MLIR utilities. For
example, you can do things like,
- op->walk([](UnregisteredOp<opName> op) { ... };
Differential D114482
[mlir] Add `UnregisteredOp` to help traversing unregistered ops Chia-hungDuan on Nov 23 2021, 3:03 PM. Authored by
Details
Add a helper class UnregisteredOp for the unregistered ops to get the
Diff Detail
Event TimelineComment Actions River@, We had discussion about this and we were thinking things like UnregisteredOp<"test.op">. It seems that we don't have a way to pass string literal for non-type template argument (literal class type in C++20 may be help?). If we want something like template<char *> then it needs to have somewhere to put the string literal in global scope. We can discuss this later. Thus I think we can extend the walk for specifying the operation name, so that we don't need to do the string comparison all the time(by leveraging the OperationName) Comment Actions Could we do something like op->clone(); cloned->walk<WalkOrder::PostOrder>(WithName("dummy"), ...) where WithName (or somesuch) is the constructor of a struct with (say) a WalkResult operator()(Operation *)? and so the string stored for the lifetime of the struct, internal to the struct one can then cache OperationName without walk needing to know anything more, we get documentation at callsite that filtering is by name, and it could be extended to match attributes and the like too (not sure if that's needed, just thinking more that string name matching here feels like it serves as an and on top of a general filtering mechanism) Comment Actions Yes, I was thinking to add a callback like shouldVisit to determine which operation we want to visit. I was not sure if we want to support it generically. Thinking the case like, the user may not know they can use OperationName so they may do the string comparison as well (And yes, here's the question, who should have the knowledge of OperationName). Then they may not need shouldVisit, they can do it in original callback. The attribute may have the same case. We can do both I think, i.e., have the generic shouldVisit callback and specialized way for certain filters like operation name. What do you think? Comment Actions That's a good point about caching the OperationName. In the context of unregistered operations, I was also thinking about adding a class that was like template <const char *name> class UnregisteredOp : public Op {,, }; that could be used in-place of the raw operation name in certain cases. We could even consider adding some build methods to it, so that it could be used over OperationState/checking the raw operation name when possible.
|
Why template this class instead of taking the string in the constructor?