[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