-
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] Add MergeCompilerRegions pass #5134
Conversation
@mbaret Sorry I haven't been following the development of a new partitioning algorithm. Is this related to annotator support for composite? |
It isn't (although I hope to handle that next). This is to help support the case where we partition into a region that has multiple outputs. |
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.
@comaniac please review the algorithm part as you also worked on it before.
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.
The algorithm behavior seems fine to me.
// By now, all the nodes have some sort of annotation. | ||
// Region merger is ExprVisitor that will update the | ||
// AnnotatedRegionSet. | ||
RegionMerger merger(regions); |
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.
This name is confusing. RegionMerger
seems like a mutator but it is actually a visitor. Maybe something like MergableRegionAnalyzer
. Or it's better to combine this one with MergeAnnotation
. The logic of MergeAnnotation
is pretty simple and it can be done in this pass as well, making this pass a real "merger".
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.
I don't think I can easily combine the two passes because of the visit order. I agree the name is slightly confusing, but it does merge 'Regions' in that you pass it an AnnotatedRegionSet and it returns a merged version of that set.
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.
The regions it merges is not a Relay graph but a separate data structure. It looks weird for a "merger" to only refer the given Relay graph and manipulate a separate data structure.
Another way I can think of to make it more reasonable is moving RegionMerger to the AnnotateRegionSet and make it optional, like:
AnnotatedRegionSet regions = AnnotatedRegionSet::Create(
expr_all_annotated, compiler_begin_op, compiler_end_op, true);
where the last argument indicates if the created regions should be merged.
Anyway for the time being, we could revisit this part in the future.
Hello, I am trying to use this (in combination with #5143) but I am getting a segfault every time I call
|
@mbaret could you reproduce the failure and try to resolve it? It crashed before partition graph so it should not be the issue of multiple output support. |
I've found the issue (was to do with changes I made to the merging during code review on the AnnotatedRegionSet patch). I've made the necessary change in this PR, but we'll also need this fix PR. I've also added in a more extensive test (based on the one in your PR) to verify the issue is resolved. |
Can you just incorporate that change as it is really short? |
also please fix @comaniac's comments |
I've incorporated that fix into this PR now. |
This pass is part of the flow to support creating compiler regions with multiple outputs. It should be called after AnnotateTarget and will merge together regions that share the same target to create larger compiler regions that can be off-loaded to external codegens. This pass implements an algorithm to ensure that during the merging, no data dependency issues are created. See the tests for an example of this case. Co-authored-by: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> Co-authored-by: Manupa Karunaratne <manupa.karunaratne@arm.com> Change-Id: Ibd99083564608d888482f57c5080109f3eefec88
This alters the behaviour of the AnnotateTarget pass to enforce the property that all compiler annotations exist along a single data flow edge. Specifically, this means they should have exactly one parent and one child. Change-Id: I0e74803a77767f4f377d17755a13a74a30909797
Deleting items from a list while iterating it seems to result in undefined behaviour which sometimes segfaults. This makes sure all the item deletion happens separately.
@mbaret Thanks for investigating and making the fixes! However, I'm still getting the segfault on call to MergeCompilerRegions in that example I posted earlier using your fixes. Are you able to run that example successfully? |
There's still another issue to resolve with this (in AnnotateRestDefault). I'll take a look at it on Monday. |
Thanks @mbaret @trevor-m @zhiics @comaniac @siju-samuel |
* [RELAY] Add MergeCompilerRegions pass This pass is part of the flow to support creating compiler regions with multiple outputs. It should be called after AnnotateTarget and will merge together regions that share the same target to create larger compiler regions that can be off-loaded to external codegens. This pass implements an algorithm to ensure that during the merging, no data dependency issues are created. See the tests for an example of this case. Co-authored-by: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> Co-authored-by: Manupa Karunaratne <manupa.karunaratne@arm.com> Change-Id: Ibd99083564608d888482f57c5080109f3eefec88 * [RELAY] Annotate compiler_ends on each edge This alters the behaviour of the AnnotateTarget pass to enforce the property that all compiler annotations exist along a single data flow edge. Specifically, this means they should have exactly one parent and one child. Change-Id: I0e74803a77767f4f377d17755a13a74a30909797 * Fix comment * Rebase *Node::make * Moved block outside for loop * Code style * Update make API * Remove comment * Remove redundant 'else's * Make one line * Fix comment * RefWrite * Fix merge ordering * Add the RFC example as a test * [FIX] Fixed merging behaviour in AnnotateRegionSet Deleting items from a list while iterating it seems to result in undefined behaviour which sometimes segfaults. This makes sure all the item deletion happens separately. * Added checks * Move comment * Update comments
* [RELAY] Add MergeCompilerRegions pass This pass is part of the flow to support creating compiler regions with multiple outputs. It should be called after AnnotateTarget and will merge together regions that share the same target to create larger compiler regions that can be off-loaded to external codegens. This pass implements an algorithm to ensure that during the merging, no data dependency issues are created. See the tests for an example of this case. Co-authored-by: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> Co-authored-by: Manupa Karunaratne <manupa.karunaratne@arm.com> Change-Id: Ibd99083564608d888482f57c5080109f3eefec88 * [RELAY] Annotate compiler_ends on each edge This alters the behaviour of the AnnotateTarget pass to enforce the property that all compiler annotations exist along a single data flow edge. Specifically, this means they should have exactly one parent and one child. Change-Id: I0e74803a77767f4f377d17755a13a74a30909797 * Fix comment * Rebase *Node::make * Moved block outside for loop * Code style * Update make API * Remove comment * Remove redundant 'else's * Make one line * Fix comment * RefWrite * Fix merge ordering * Add the RFC example as a test * [FIX] Fixed merging behaviour in AnnotateRegionSet Deleting items from a list while iterating it seems to result in undefined behaviour which sometimes segfaults. This makes sure all the item deletion happens separately. * Added checks * Move comment * Update comments
This is part of the infrastructure necessary to support multiple outputs in the BYOC graph partitioning framework. It corresponds to step 3 of the flow outlined here and implements the algorithm described in this RFC. In summary, it merges together consecutive operators supported by the same target while ensuring that no data dependency issues are created.
This PR depends upon the utility functions provided by the AnnotationRegionSet PR and the Improved graph partitioner.