There’s nothing wrong with this, but let’s not invent additional terminology where one exists already.
FYI, the sets of transitive producers(users) of an operation are called backward(forward) slice, respectively.
Thanks for this vital information! It is really useful for me to align with existing terms. Also, I think we can rename this pass with more clear one in the future.
It’s not clear what “hardware analysis layer” this refers to, we have no such thing in MLIR as far as I know, and it doesn’t seem to be a part of the proposal.
Sorry for this confusing. It seems a part of IREE. Or you can treat it as Target Description of this proposal. Anyway, it just provides resource hints of specific device for cost model to make final decision like which candidate to fuse during runtime.
It’s okay to have an iterative implementation of producer+consumer fusion starting from a given op with some cost model upstream IMO, preferably with a possibility to inject that cost model into the iteration logic, e.g., as a callback accepting the currently fused loop structure and a candidate.
Yes, I agree and that is what I am trying to do.