[PATCH] D113511: [mlir] Optimize usage of llvm::mapped_iterator
Chris Lattner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 9 14:12:35 PST 2021
lattner added a comment.
Whoa, thank you for tackling this! The trick with `getFunction()` is interesting, I hadn't thought about that.
I'm curious: did you consider splitting this into a new `static_mapped_iterator` class instead of keeping the mapped_iterator design of having a stored function? The static_mapped_iterator could be implemented in roughly the same way, but instead of returning a closure, it could just invoke the "getFunction" member as a static member. This would eliminate the lambdas and the function_ref in ResultElementTypeIterator.
I'm not sure if that makes sense. I'm imagining that clients would look like this:
template <typename UseIteratorT, typename OperandType>
class ValueUserIterator final : public llvm::static_mapped_iterator<...
public:
/// Return the map function used by this iterator.
static Operation *mapElement(OperandType &value) {
return value.getOwner();
}
This would reduce pressure on the optimizer (good for -O0 builds in particular) and force a cleaner model.
WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113511/new/
https://reviews.llvm.org/D113511
More information about the llvm-commits
mailing list