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.