Problem
While enabling SmolLM on RustNN/CoreML, we need exported Slice/Range sizes to retain their runtime dependencies, not just a dimension name and allocation bound. A literal 4096 cannot safely be recovered as the active sequence length, and a label such as past_sequence_length + 1 does not by itself prove that they relate. I do have this working on my local devices with extra work that I wouldn't expect regular app developers to have/want to do (see related issues below for latest demo updates).
In current Slice lowering, dynamic end metadata is reused as the size label even though nonzero starts, clipping and strides can change that extent. Range lowering also derives relationships from dimension-name spelling. Separately, shape-tensor values Must Not be confused with the shape of the tensor containing them (that was annoying to chase down).
Is it possible to preserve a typed producer-based shape dependency through ONNX import, optimization, and WebNN serialization, AND reject unsupported relationships instead of silently freezing their maxima?
Needed coverage
This is separate from the positive-stride Slice window bug (start 2/end 10/step 2 on length 16 should produce four values). It also does not require changing current WebNN Slice semantics.
Context:
SmolLM with RustNN on Apple Watch tracking,
runtime Slice draft,
RustNN dynamic-shape work,
WebNN dynamic-shape proposal.
Problem
While enabling SmolLM on RustNN/CoreML, we need exported Slice/Range sizes to retain their runtime dependencies, not just a dimension name and allocation bound. A literal
4096cannot safely be recovered as the active sequence length, and a label such aspast_sequence_length + 1does not by itself prove that they relate. I do have this working on my local devices with extra work that I wouldn't expect regular app developers to have/want to do (see related issues below for latest demo updates).In current Slice lowering, dynamic end metadata is reused as the size label even though nonzero starts, clipping and strides can change that extent. Range lowering also derives relationships from dimension-name spelling. Separately, shape-tensor values Must Not be confused with the shape of the tensor containing them (that was annoying to chase down).
Is it possible to preserve a typed producer-based shape dependency through ONNX import, optimization, and WebNN serialization, AND reject unsupported relationships instead of silently freezing their maxima?
Needed coverage
This is separate from the positive-stride Slice window bug (start 2/end 10/step 2 on length 16 should produce four values). It also does not require changing current WebNN Slice semantics.
Context:
SmolLM with RustNN on Apple Watch tracking,
runtime Slice draft,
RustNN dynamic-shape work,
WebNN dynamic-shape proposal.