Decomposing aggregate types into more primitive types on
calling convention boundaries seems like a fairly separable concern. If
desired, we can resurrect it as a "adjust calling conventions"
pattern/pass, which just does this calling convention adjustment.
Actually, a need for that has already arisen in the community, and we
should develop this functionality with that use case in mind:
https://llvm.discourse.group/t/rewriting-function-calls-and-signatures/1953/2
Details
- Reviewers
herhut dfki-mako bondhugula
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The basic idea behind these generic type converts was to provide a highly customizable way to decompose and rewrite tuple types.
However, if there are no real users and as you are currently refactoring these parts into a separate pass anyway, it might be a good idea to simplify these conversion patterns.
See this CL for additional comments on the general refactoring process.
Ping, @bondhugula any chance you could weigh in here? I think there is general agreement on this direction, but I wanted to make sure that that we can find a solution for your use case, if this tuple decomposition still remains necessary.
But this would break the mhlo to lmhlo conversion where the canonical form of an incoming TF model lowered to mhlo is to return a tuple of tensors, and that tuple gets unpacked into a list of memref output arguments on the function. If this functionality can be improved with a better separation of concerns, it may be good to do that. But we shouldn't delete this until then! The way it is now: the functionality is clearly defined with its own proper test cases. And it has an out of tree user in the mlir-hlo repo (-hlo-legalize-to-lhlo pass) - please don't remove this! :-)
It sounds like a pre-pass that takes mhlo functions and makes them return multiple results instead of a tuple would be sufficient. I'll prepare a patch.
Uday and I chatted, and we weren't able to find anything downstream that uses this, and it seems that any potential future issues can be addressed by a targeted pass without requiring any changes to bufferization.
Let's move forward with this!
Actually, it sounds like the direction we want to go with this is to split this functionality out. I'll do that in a separate patch.
Actually, it sounds like the direction we want to go with this is to split this functionality out. I'll do that in a separate patch.
Sounds good to me. Let's do this step by step in separate patches. Are you going to close the CL for now?
Yes, abandoning. I'm first removing AppendToArguments (a separate, but code-wise not orthogonal cleanup) in https://reviews.llvm.org/D90778
Then I'll split this functionality out into a "TypeExpander" / "TypeDecomposer" independent utility.