Thinking more about this, the role of my proposed SchedulableOpInterface is to associate an OperatorType to an Operation. But the Scheduling infrastructure already has this ability: Problem::setLinkedOperatorType(Operation *op, OperatorType opr). If a pass doing Scheduling uses attachInterface<SchedulableOpInterface> to make some associations, it’s going to turn right around and call setLinkedOperatorType based on these, and I’m not sure the indirection has merit today.
Before I go any further, I’m going to try writing a pass to perform Scheduling using the existing methods for expressing an operator library. Hopefully that will make it more clear what interface(s) would actually simplify things, other utilities we could add, how OperatorType might evolve, etc.
EDIT: digging into this a bit more, it seems like if we do provide an interface to be attached, we could potentially get rid of setLinkedOperatorType, and update the Scheduling internals to use the interface rather than getLinkedOperatorType. I’m still playing around with a small example, but I’m starting to see how re-working the Scheduling internals around interfaces could be nice.