Skip to content
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] Start porting pass to the pass manager #3191

Merged
merged 2 commits into from
May 24, 2019

Conversation

MarisaKirisame
Copy link
Contributor

@zhiics @jroesch is this fine? If so, I will convert the rest in the same manner.

@zhiics
Copy link
Member

zhiics commented May 14, 2019

@MarisaKirisame Thank you for the effort. For registration this is okay to me. But there are still some problems we probably want to discuss:

  • I think that PassContext should be taken by every pass so that we can do things like error reporting in each pass func.

  • Should we invoke FuseOpPass(mod, ctx) and FuseOp(xx) separately, or with a unified interface? Separate invocation is okay to me.

  • FuseOp should be able to take Function as well. Should we treat it as a module pass?

@jroesch @tqchen Any other concerns?

@MarisaKirisame
Copy link
Contributor Author

@zhiics I dont think it should be able to take function. Everything will work Module -> Module inside the pass manager, and if you want function to function, you can use the old api which will still be open.

@zhiics
Copy link
Member

zhiics commented May 15, 2019

@MarisaKirisame Yes, you are right everything is Module->Module. But we also have FunctionPass which can take a pass function and apply it to each Function in a module, which is similar to what you are doing to update every Function here. It will return the new Module with updated functions.

@MarisaKirisame
Copy link
Contributor Author

MarisaKirisame commented May 16, 2019

@zhiics I see.

@MarisaKirisame
Copy link
Contributor Author

should functionpass return new Module instead of update inplace though? @zhiics @jroesch I am for the new Module approach.

@zhiics
Copy link
Member

zhiics commented May 16, 2019

@MarisaKirisame I am okay with either way. I updated inplace because we usually cannot run multiple function level opts in parallel.

@MarisaKirisame
Copy link
Contributor Author

@zhiics I see. I think leaving the old module intact is better because it allow one to debug by just looking at the intermediate Modules.

@MarisaKirisame
Copy link
Contributor Author

@zhiics

  • Should we invoke FuseOpPass(mod, ctx) and FuseOp(xx) separately, or with a unified interface? Separate invocation is okay to me.
    They should be unified into a FunctionPass. I will just do it in twostep: expose a FunctionPass api, which is relatively easy, and provide most of the benefit we want, and remove the old api, which require more work (and can be parallelized).
  • I think that PassContext should be taken by every pass so that we can do things like error reporting in each pass func.
    You are correct. I will do it in the second PR.
  • FuseOp should be able to take Function as well. Should we treat it as a module pass?
    It is fixed now. I just did not see that FunctionPass also work on Module earler.

@zhiics
Copy link
Member

zhiics commented May 16, 2019

@MarisaKirisame I don't think we need to change the API to pass in a Module because it will execute on a Module

https://github.com/dmlc/tvm/blob/4b302cf88c9bfbdfbdd2015f46680678db2eae62/src/relay/pass/pass_manager.cc#L133

@MarisaKirisame
Copy link
Contributor Author

@zhiics yes, but some pass might need to additionally take a module, to work on a function (to handle globalvar).
PartialEval is one of them. I think we should leave the possibility open.

@zhiics
Copy link
Member

zhiics commented May 16, 2019

@MarisaKirisame Yes, I understand. As I mentioned in the RFC, it seems every pass will need Module as we want ErrorReporter.

EDIT: I was thinking if it is necessary to encode into to PassContext...

@MarisaKirisame
Copy link
Contributor Author

@zhiics it is definitely possible, whetthrt we should or not is another issue. What was the design intent of PassContext?

@zhiics
Copy link
Member

zhiics commented May 16, 2019

@MarisaKirisame Let's bring @jroesch in discussion. PassContext was designed to only take some internal information that is used by a pass. Originally we proposed to have PassState instead which took Module as well.

/*! \brief Aggressive constant propagation/constant folding/inlining.
* It will do as much computation in compile time as possible.
* It has two benefit: remove runtime overhead, and allow more optimization (typically fusion).
* As a side effect, code size will explode.
*/
Expr PartialEval(const Expr& e);

inline pass::Pass PartialEvalPass() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not use inline function and put all implementation in the corresponding pass file.

@MarisaKirisame
Copy link
Contributor Author

MarisaKirisame commented May 23, 2019

@tqchen I address your comments. can you give another round of review?

@zhiics
Copy link
Member

zhiics commented May 23, 2019

@MarisaKirisame This looks good to me now. Do we have more passes to register?

@MarisaKirisame
Copy link
Contributor Author

@zhiics yes. for example, simplify inference is not exposed in the C++ side.
there is a few more, and I dont think chasing through them is a good idea as they scatter accross the code base.
I think I can do them as I move the old optimize function into the new style (in the next PR), is it fine with you?

@zhiics
Copy link
Member

zhiics commented May 23, 2019

@MarisaKirisame Yes, that's totally fine to me. Thank you. Another thing we need to keep in mind or probably add to the RFC is that we should add PassContext to the passes so that they can take internal thing like error reporting.

@@ -271,13 +272,17 @@ TVM_DLL tvm::Array<TypeVar> AllTypeVars(const Type& t, const Module& mod);
*/
TVM_DLL Expr DeadCodeElimination(const Expr& e);

transform::Pass DeadCodeEliminationPass();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given that transform namespace has been merged in. Please move them to transform.h . Under the same name

Pass DeadCodeElimination();

using namespace runtime;
using std::function;

Pass DeadCodeEliminationPass() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of putting these in pass.cc , directly move it to dead_code.cc Note that we might remove the original DeadCodeElimination function and only keep this one

int opt_level,
const std::string& name,
const tvm::Array<tvm::Expr>& required);

Pass DeadCodeElimination();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

document each function using the doxygen format

*
* Implements structural hashing of a Relay type.
*
* \param type the type to hash.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems the location of StructualHash does not have to change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanna move the big one down, and have the small one together, so it is easier to read.

int opt_level,
const std::string& name,
const tvm::Array<tvm::Expr>& required);

Pass DeadCodeElimination();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mark the declaration with prefix TVM_DLL so that it is exposed in the dynamic library.

*
* \return The pass.
*/
TVM_DLL Pass FuseOps(int fuse_opt_level);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let us allow fuse_opt_level=-1 (automatic mode) which allows the op_level to equal PassContext::Current()->opt_level

update

save

do

fix build

lint

do

do

fix

lint

save

address comment

ci

save

fix conflict
@tqchen tqchen merged commit 89a88c5 into apache:master May 24, 2019
@tqchen
Copy link
Member

tqchen commented May 24, 2019

Thanks, @MarisaKirisame , this is merged

wweic pushed a commit to wweic/tvm that referenced this pull request Jun 26, 2019
wweic pushed a commit to neo-ai/tvm that referenced this pull request Jun 27, 2019
@MarisaKirisame MarisaKirisame deleted the port branch July 13, 2019 20:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants