MLBEDSW-5844: Inconsistent calculation of read shapes
- This bug causes a regression in the use of unpack and split operators
- The bug is due to the read_shapes attribute being an absolute calculation
for slice and strided_slice, but a relative one for unpack and split
- The fix is to consistently treat the attribute as a shape relative to the
read_offset
Signed-off-by: Tim Hall <tim.hall@arm.com>
Change-Id: I4504b161be507ea22ca6ee40fbe7808bfe049405
diff --git a/ethosu/vela/high_level_command_stream.py b/ethosu/vela/high_level_command_stream.py
index abf6d83..cf31aa5 100644
--- a/ethosu/vela/high_level_command_stream.py
+++ b/ethosu/vela/high_level_command_stream.py
@@ -79,13 +79,13 @@
if len(new_start_coord) >= 2:
stride = strides[2]
# if the current op was combined with a split slice read then the valid ifm range is given by the output
- # of the split op
+ # of the split op (which is defined by the read offset and the read shape)
if split_offset is None:
new_start_coord[-2] = max(new_start_coord[-2] * stride - skirt[1], 0)
new_end_coord[-2] = min(new_end_coord[-2] * stride + skirt[3], ifm_shape.width)
else:
new_start_coord[-2] = max(new_start_coord[-2] * stride - skirt[1], split_offset[-2])
- new_end_coord[-2] = min(new_end_coord[-2] * stride + skirt[3], split_shape[-2])
+ new_end_coord[-2] = min(new_end_coord[-2] * stride + skirt[3], split_offset[-2] + split_shape[-2])
if len(new_start_coord) >= 3:
stride = strides[1]