-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[Relay][Pass] Only allow Module -> Module for opts managed by pass infra #3430
Conversation
e9494d0
to
2624da0
Compare
raise TypeError("Unknow mode: {}".format(mode)) | ||
|
||
|
||
def OptimizeOnExpr(expr, passes): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this be a function instead of a class style pass constructor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was using this just to keep it like an optimization as the other ones.
for the ANF pass, the 'implicit update' is needed to traverse every global var used. however, with function module, this is not needed anymore. maybe you can remove the implicit update of the code? for PE, I think it should be a Mod -> Mod at the impl level, and I will fix it. |
@zhiics can you not pass 'higher_order' rn? There isnt much case where the other mode is supported, and I personally think it should be deprecated, or at least, it should only be for expert who know what they are doing. |
8621b9e
to
3c4714a
Compare
@MarisaKirisame I tried to fix to ANF and PE in the commit. You can probably take a look. For |
after some thinking, phasing AD as a pass is really bad. can you revert this change? thank you. |
@MarisaKirisame Okay. I will revert the gradient pass. Later, we will have an analysis file and put the analysis passes there. |
@zhiics i agree. Thx. |
@MarisaKirisame reverted |
Re: AD as a Pass. I still think it should be Module->Module, we just need to debate about the APIs. |
@tqchen this is a reasonable design, however there are other ways to do this, and I am thinking of doing a redesign/re-implementation of the AD. I feel like it could be delayed a bit. Regardless, having it as FunctionPass seems like the wrong design. |
The main motivation is that we want to consolidate everything under Module->Module. If @MarisaKirisame you can quickly come up with a Module->Module style API proposal, I recommend we do so, given that it won't affect implementation as much. |
Yes, name of interest looks like a plausible way. I will keep this pass not touched in this PR. |
Re: AD we should add a special |
…fra (apache#3430) * [Relay][Pass] Only allow Module -> Module for opts managed by pass infra * revert gradient pass
…fra (apache#3430) * [Relay][Pass] Only allow Module -> Module for opts managed by pass infra * revert gradient pass
…fra (apache#3430) * [Relay][Pass] Only allow Module -> Module for opts managed by pass infra * revert gradient pass
This PR moves some passes from to the pass manager. The summary of the changes:
to a normal form implicitly modifies the module but only returns an updated expr. This may cause problems since some updated functions in the module might be lost. I changed to it a module pass that returns a module to avoid losing information.
Some unit tests in DCE don't have typing info. We can run
Expr -> Expr
opts on this them without types. However, as relay is strongly typed (at least everything in a module should be strongly typed), this PR adds types to them.Partial Evaluation seems to need some more work for moving into the pass infra. I think it should be a module pass because it could evaluate the functions and then apply DCE to delete some of the dead ones. It looks to me we might need a global DCE pass to work on the module level and be able to delete functions. Otherwise, we might need to rely on inlining and outlining.
cc @jroesch @tqchen @MarisaKirisame @wweic @icemelon9 @slyubomirsky