Some ops requires redundant data in MLIR C++ API

[joelberkeley]

What happened?

ConvertOp requires a type to specify the output. But the API requires a tensor type, including shape, not just an element type. This makes no sense for ops like ConvertOp, where the return shape is uniquely determined by the other arguments. This is confusing and cumbersome for API callers, and encourages bugs where the specified shape is invalid.

Similar ops where both shape and type are required by the API:

• DotGeneralOp : the result element is the same is the input type. Similarly the shape is uniquely inferrable from args.
• ReshapeOp : the result element is the same is the input type.

Steps to reproduce your issue

Call ConvertOp via C++

Version information

No response

[GleasonK]

I believe we have ConvertOp covered - convert only specify element type.

MLIR generates multiple signatures for each op, and the one with an explicit fully-specified result type is the default one generated for all ops. But when more type info is available (and some custom builder specifications) others are generated.

That said I agree we're missing some, specifically Reshape and DotGeneral as you've called out. We have wrappers in our C++ Builder API (reshape, dot_general) but we should move these to be more built-in on the op itself (custom decls like this one on ConvertOp).