-
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] call graph for relay #4922
Conversation
54af091
to
7e39f02
Compare
I wonder if we should create a folder for analysis and put call graph there instead of at the root folder of relay. |
@icemelon9 Yeah, I had the same thoughts, but it seems we currently put other analysis passes under |
I mean in python, there's analysis.py in the python/relay. |
@icemelon9 ahh, make sense. We probably want to refactor the root directory to reflect the organization of c++ side. Currently, most of things are under the root directory. |
Got it. We can do this in a follow up PR. |
Note: it is fine it keep things as it is for now, we will likely need to move to the common ir after we finished the unified IR refactor, so call graph include both tir and relay |
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.
Suggest to open an issue to track namespace refactoring after this is merged.
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.
Thanks for the contribution. I have minor comments. I am just trying to understand the pass.
For my knowledge, how will this be used? You mentioned inlining. But, when do we have multiple functions in the same module?
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.
Requesting minor typo changes
@anijain2305 Thanks for reviewing. Call graph is usually used for inter-procedural level analysis. For example, you might have multiple functions that form a call chain (a->b->c). In this case, we need to think about the orders of them when performing some optimizations. For inlining, we need to inline c to b first and then b->a. We will have multiple functions in a module in many cases. One most common case is that whenever you use functions in prelude, you may have multiple functions in a module. |
* call graph for relay * CallGraphEntryNode->CallGraphEntry, __getitem__->print_var * fix typos
* call graph for relay * CallGraphEntryNode->CallGraphEntry, __getitem__->print_var * fix typos
* call graph for relay * CallGraphEntryNode->CallGraphEntry, __getitem__->print_var * fix typos
This PR introduces call graph for Relay. It is important for inter-procedural analysis, like inlining. It is largely inspired from the LLVM implementation here: https://llvm.org/doxygen/CallGraph_8h.html