[Relay] Improve reduction op layout propagation for packed input #9253
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Address the issue I raised in #9048 (comment)
So previously,
layout_transform
is always inserted before reduction ops if the input is in a packed layout:After this PR,
layout_transform
is pushed to happen after reduce ops:I believe the latter one is better because
layout_transform
can potentially be fused with other ops following reduce ops, while in the former caselayout_transform
always happen on a bigger input. For example, in theefficientnet_v2
model, alllayout_transform
aftermean
ops are fused with other injective ops like this, which is much better than the previous situation where more than 80 nakedlayout_transform
ops are inserted before everymean
op.The logic to determine the correct layout is slightly complicated, hopefully the comments I added help.
cc @comaniac @yzhliu