That is confusing. Could you share a patch where you’re seeing this behavior? From what you’ve got here it seems this should indeed be a linalg op and I suspect there’s some other issue with code or understanding that’s causing you to see this result.
Yes I think you need to derive from LinalStructuredBase_Op.
I would recommend to start from an existing operation such as the CopyOp when implementing a new one. Also consider if you want to use the OpDSL to define your own operation. It allows you to specify the operation in Python (Linalg OpDSL - MLIR) and translate it to a C++ operation via a yaml configuration file.
Not directly related to the question, but I’d like to point out that I would recommend NOT to add a such op to Linalg in this way, either to upstream or local. The padding attributes will stop many opportunities from Linalg Transform, e.g., tile+fusion. There are couple options to support the op:
You can use a linalg.pooling_sum_* + div (or a linalg.generic) to represent the op in Linalg.