Page MenuHomePhabricator

[mlir] Remove notion of "decompose values" from BufferizeTypeConverter
AbandonedPublic

Authored by silvas on Oct 22 2020, 3:28 PM.

Details

Summary

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

Diff Detail

Event Timeline

silvas created this revision.Oct 22 2020, 3:28 PM
silvas requested review of this revision.Oct 22 2020, 3:28 PM

+uday who seems like might be using this.

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.

bondhugula requested changes to this revision.Mon, Nov 2, 9:25 PM

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! :-)

This revision now requires changes to proceed.Mon, Nov 2, 9:25 PM
silvas added a comment.Tue, Nov 3, 8:59 AM

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.

silvas added a comment.Tue, Nov 3, 9:35 AM

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!

silvas edited the summary of this revision. (Show Details)Tue, Nov 3, 10:05 AM
silvas added a comment.Tue, Nov 3, 3:37 PM

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?

silvas abandoned this revision.Thu, Nov 5, 9:40 AM

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.