Re-inplace slice_copy with slice

[metascroy]

🚀 The feature, motivation and pitch

Before to_executorch, there are view_copy nodes in the graph. During to_executorch, we replace view_copy nodes with view nodes before memory planning: https://github.com/pytorch/executorch/blob/main/exir/program/_program.py#L757-L761

These get emitted to view ops here: https://github.com/pytorch/executorch/blob/main/exir/emit/_emitter.py#L944-L978

The view op is implemented here: https://github.com/pytorch/executorch/blob/main/kernels/prim_ops/et_view.cpp

We want to do the same for contiguous slices. If a graph has a contiguous slice, we want to replace it with a lightweight slice kernel, rather than a slice_copy kernel.

If interested in this task, please reach out to @metascroy. Happy to guide you through it :)

cc @JacobSzwejbka

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

[JacobSzwejbka]

Ideally this pass works for other dim orders then the default but that can be a follow up

[Valkyrja-Design]

Hi @metascroy , if this is still available can I work on this (will probably require some guidance)?

[kitrakrev]

Hi @metascroy , Is this still available ?

[yujiaoliang]

After digging into the current view lowering path, it seems that et_view is the only existing prim op that models aliasing semantics across EXIR, memory planning, and runtime.

For slice_copy, simply replacing it with view doesn’t appear sufficient, since et_view is limited to reshape semantics and does not capture offset/stride information.

From what I can tell, supporting a slice-view-like behavior would likely involve:

1. introducing a new prim op with explicit alias semantics, and
2. providing a corresponding runtime kernel similar to et_view.

Before prototyping anything, I wanted to sanity-check whether this direction aligns with the intended design, or if there is an existing mechanism I might be overlooking.
@JacobSzwejbka @metascroy

[iRAFEEK]

Hi @metascroy — I'm a CodePath open-source student and I'd like to take this on. My plan is to model a new ReplaceSliceCopyWithSlicePass on the existing ReplaceViewCopyWithViewPass in exir/passes/: detect contiguous slice_copy nodes and re-inplace them as a lightweight slice, leaving non-contiguous slices on the existing copy path. I'd add an et_slice kernel mirroring et_view.cpp and wire emission through _emitter.py. Does that approach sound right to you, and is there anything you'd want me to watch out for on the contiguity check? Happy to be guided — thanks for offering!

[metascroy]

Hi @metascroy — I'm a CodePath open-source student and I'd like to take this on. My plan is to model a new ReplaceSliceCopyWithSlicePass on the existing ReplaceViewCopyWithViewPass in exir/passes/: detect contiguous slice_copy nodes and re-inplace them as a lightweight slice, leaving non-contiguous slices on the existing copy path. I'd add an et_slice kernel mirroring et_view.cpp and wire emission through _emitter.py. Does that approach sound right to you, and is there anything you'd want me to watch out for on the contiguity check? Happy to be guided — thanks for offering!

Hi @iRAFEEK, AFAIK this has not been implmented yet if you want to give it a try.

[iRAFEEK]

Thanks @metascroy! I've opened #21552 with the first piece: a ReplaceSliceCopyWithSlicePass that correctly detects contiguous (outermost-dim, unit-step) slice_copy nodes eligible for re-inplacing, plus unit tests. The zero-copy rewrite itself is gated on the offset-aliasing design — I'd love your input there, since a slice aliases a sub-region at a non-zero offset (unlike view which aliases the whole buffer). Happy to iterate!