-
Notifications
You must be signed in to change notification settings - Fork 527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Shape Information Into DecomposeComplexOps Patterns #3312
Comments
I think it's ok to apply shape infer in decomposition when it's a simple op. But we find that it's difficult to apply shape infer on |
I complete the case "DecomposeAtenTriuOp" in #3330. Please give me some suggestions, and then I will complete the other cases in the same way. |
I see. If you want, I can take a look and see if there is a nice way to add the shape information in without clogging up the code too much. |
…uOp (#3330) I am trying to eliminate 'getWithLeastStaticInformation' in DecomposeAtenTriuOp. Could you provide me with some suggestions? @qingyunqu @zjgarvey See issue #3312
…uOp (llvm#3330) I am trying to eliminate 'getWithLeastStaticInformation' in DecomposeAtenTriuOp. Could you provide me with some suggestions? @qingyunqu @zjgarvey See issue llvm#3312
…uOp (llvm#3330) I am trying to eliminate 'getWithLeastStaticInformation' in DecomposeAtenTriuOp. Could you provide me with some suggestions? @qingyunqu @zjgarvey See issue llvm#3312
) also add shape infer in decomposition, see #3312
Many pass pipelines rely on --torch-decompose-complex-ops, but do not include shape inference passes afterwards. For large models, the complex computations performed in shape inference passes take a significant amount of time to perform and are not as reliable as explicitly specifying the result types by hand. The only downside to adding these shapes by hand is the minor expense of code complexity, but with the development of appropriate helper functions such as Torch::unsqueezeTensor as a replacement for
rewriter.create<AtenUnsqueezeOp>(loc, baseType,...)
as seen here, the potential downside to code readability should rendered completely irrelevant.As a design decision for the short term (before larger changes like fx decompositions are added), I'd like to come to a consensus with the community to avoid using
in decompose complex ops conversions, and to request authors of recent conversions to go back and add shape information into their code.
Here is the very short list of decompose complex ops passes which currently rely on shape inference:
If anyone in the community has strong feelings in opposition to this change, please feel free to discuss here.
The text was updated successfully, but these errors were encountered: