Fold non-matching end permutes instead of discarding the region (#22293) - #22293
Fold non-matching end permutes instead of discarding the region (#22293)#22293abeakkas wants to merge 1 commit into
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22293
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 Cancelled Job, 1 Unrelated FailureAs of commit 23815c1 with merge base c27baa8 ( CANCELLED JOB - The following job was cancelled. Please retry:
BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
@abeakkas has exported this pull request. If you are a Meta employee, you can view the originating Diff in D117939968. |
This PR needs a
|
…rch#22293) Summary: `RemovePermutesAroundElementwiseOps` gave up on an entire region whenever it reached an outgoing permute that was not the inverse of the region's start permute, so a single mismatched boundary cost every permute removal in that region. Such a permute is now kept and its permutation rewritten to absorb the start permute being removed. With the producer back in the original layout, `permute(permute(x, start), end)` is `permute(x, R)` for `R[k] = start[end[k]]`, so the consumer sees the same tensor and one permute still disappears. No permute is added on a live edge: the existing matching case is just the instance where `R` is the identity. Since a permute can now be rewritten in place while staying wired, `_subgraph_edges_are_current` also re-validates that an `edges_in` permutation still matches what the candidate was planned against. Reviewed By: DrJessop Differential Revision: D117939968
fe1b261 to
de3dfd0
Compare
…rch#22293) Summary: `RemovePermutesAroundElementwiseOps` gave up on an entire region whenever it reached an outgoing permute that was not the inverse of the region's start permute, so a single mismatched boundary cost every permute removal in that region. Such a permute is now kept and its permutation rewritten to absorb the start permute being removed. With the producer back in the original layout, `permute(permute(x, start), end)` is `permute(x, R)` for `R[k] = start[end[k]]`, so the consumer sees the same tensor and one permute still disappears. No permute is added on a live edge: the existing matching case is just the instance where `R` is the identity. Since a permute can now be rewritten in place while staying wired, `_subgraph_edges_are_current` also re-validates that an `edges_in` permutation still matches what the candidate was planned against. Reviewed By: DrJessop Differential Revision: D117939968
de3dfd0 to
23815c1
Compare
Summary:
RemovePermutesAroundElementwiseOpsgave up on an entire region whenever itreached an outgoing permute that was not the inverse of the region's start
permute, so a single mismatched boundary cost every permute removal in that
region.
Such a permute is now kept and its permutation rewritten to absorb the start
permute being removed. With the producer back in the original layout,
permute(permute(x, start), end)ispermute(x, R)forR[k] = start[end[k]],so the consumer sees the same tensor and one permute still disappears. No
permute is added on a live edge: the existing matching case is just the
instance where
Ris the identity.Since a permute can now be rewritten in place while staying wired,
_subgraph_edges_are_currentalso re-validates that anedges_inpermutationstill matches what the candidate was planned against.
Reviewed By: DrJessop
Differential Revision: D117939968