We were using memref.subview with negative strides without any issues in our pipeline for some time, but found that it is forbidden now after implementation switched to StridedLayoutAttr.
I noted that omission in my review of the change and negative strides being the reason we need a different value than -1 to encode ?.
Still we don’t have upstream or internal downstream usage of negative strides today.
Could you please propose a 2-3 tests?
I imagine having a single test upstream to “justify usage” may not be enough for eternity.
Thanks
Also @ftynse
Here is my attempt ⚙ D134147 [mlir] Allow negative strides and offset in StridedLayoutAttr
We don’t have specific case for negative offset, but added support as well for consistency. There are some examples in canonicalize.mlir. Also, I don’t have any experience with mlir Parser api, so I’m not sure everything is correct there.
I don’t object to negative strides specifically, but the test coverage of this use case is close to zero. Do we have a test of subview lowering to LLVM? What is even the semantics of that, i.e., is the user supposed to provide an offset so as to support reversal or is that automatic? Can we have mixed positive and negative strides?
Existing llvm lowering works for us for negative strides, but we are using only 1D case so far. I will try to add test for it to the patch.
Also, we don’t use it now, but I’m interested in motivation behind ‘no internal aliasing’ rule.