This is still subtle, but I think the test cases are sufficient to show
that it works.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
90 ms | x64 windows > LLVM.CodeGen/XCore::threads.ll |
Event Timeline
This seems to do the right thing, I just don't understand why.
mlir/lib/Dialect/Shape/IR/ShapeCanonicalization.td | ||
---|---|---|
36 | I am somewhat puzzled what this means. It creates a new Shape_ConstShapeOp with the given $ty which is the value? Why is it called ty then? How does the type come into this? Is it somehow inherited from the original operation? |
- Rename argument from $ty to $arg
mlir/lib/Dialect/Shape/IR/ShapeCanonicalization.td | ||
---|---|---|
36 | $ty is just me coming up with a weird name. Renamed it to be more consistent. The type is inherited from the original. |
mlir/lib/Dialect/Shape/IR/ShapeCanonicalization.td | ||
---|---|---|
35 | Maybe add a small comment here about how the types are preserved. | |
mlir/test/Dialect/Shape/canonicalize.mlir | ||
886 | I think both these test cases and be reduced. The select isn't needed (return/func are sufficiently picky about the type to be representative for this test) and the shape.const_shape that we don't fold is not needed after the select is removed. | |
895 | random comment (unrelated to patch): I'm surprised that shape.const_shape [3] : tensor<1xindex> isn't rejected by the verifier. The ODS declaration has the return of Shape_ShapeOrExtentTensorType, which only allows !shape.shape or tensor<?xindex> (but seemingly not tensor<1xindex>). |
mlir/test/Dialect/Shape/canonicalize.mlir | ||
---|---|---|
895 | That's because: def Shape_ExtentTensorType : 1DTensorOf<[Index]>, Shape_ExtentTensorType allows any 1D tensor of index elements. |
mlir/test/Dialect/Shape/canonicalize.mlir | ||
---|---|---|
895 | Oh, I think I found it. Shape_ExtentTensorType inherits from 1DTensorOf<[Index]> but is BuildableType that creates tensor<?xindex>. That's kind of sketchy because BuildableType is supposed to be for types that only have one representation, which doesn't seem to be the case for Shape_ExtentTensorType if it also allows tensor<Nxindex> along with tensor<?xindex>. https://mlir.llvm.org/docs/OpDefinitions/#type-inference Buildable Types Some type constraints may only have one representation, allowing for them to be directly buildable; for example the I32 or Index types. Types in ODS may mark themselves as buildable by setting the builderCall field or inheriting from the BuildableType class. |
Maybe add a small comment here about how the types are preserved.