Better layering for `InferShapedTypeOpInterface`

MLIR
2

These are 3 separate interfaces in my mind.

  • reifyReturnTypeShapesPerResultDim is a dynamic transfer function for reifying IR that computes concrete shapes. By restricting itself to ranked types, it is able to take a very unopinionated representation of shapes (individual SSA index values per dimension) and so is suitable for extremely widespread use, especially across the codegen stack that is naturally already limited to ranked types.

  • reifyReturnTypeShapes implements a dynamic transfer function for computing concrete shapes as well. The use of tensor<?xindex> is basically an implementation detail of the shape dialect though, and limits the applicability to systems that buy into its premises. The use of builtin types to makes it seem like a more “universal” representation of shapes than it really is. This part of the interface should be moved to be specific to the shape dialect and kept separate from the rest. We might want an adaptor to implement it in terms of reifyReturnTypeShapesPerResultDim.

  • inferReturnTypeComponents is a generic static transfer function (i.e. for calculating static types, such as tensor<?x4x?xf32>). It has a signature suitable for use in builders for inferring result types (via the InferTensorType trait). It also has the element type and an opaque “attribute” mixed in, and I think it was meant for a more generic shape+elementtype+layout/etc. inference process, but that doesn’t seem to have materialized. It should be its own interface, and probably stripping it down appropriately to its current application and having it better integrated with InferTypeOpInterface would be nice.

1 Like