A cast-like operation is one that converts from a set of input types to a set of output types. The arity of the inputs may be from 0-N, whereas the arity of the outputs may be anything from 1-N. Cast-like operations are removable in cases where they produce a "no-op", i.e when the input types and output types match 1-1.
This fold doesn't seem right, as many things that we could consider to be "casts" can be lossy. for example, consider if sitofp and fptosi were a single op (like we do for index_cast an others). Then this could fold away an intermediate truncation to integer.
I was thinking of the cases that happen during dialect conversion. During conversion you can end up with a 1->0 conversion (most often during function signature conversion), i.e. where a type gets dropped. If uses of the original value still linger around, we have to insert a cast operation that temporarily materializes that value.
Thanks for cleaning this up!
|1077 ↗||(On Diff #317082)|
nit: kind of confusing to see this plural but only used for one type. Would suggest saying type(s).
Also, I don't see a test for the multiple-result case, multiple operand case, or 0-operand case. I don't think the anycast patch will include it (it allows all type combinations, right?), so it might be worth adding a test op.
Can't this code be simpler, something like:
return input && output && input == output && input.hasRank())
since the tensor types are uniqued? You only need the more complicated code if you're using verifyCompatibleShape instead of shape equality IIRC.
btw Paul taught me that !listconcat(x, y) can be spelled as x # y which is much nicer for this sort of use case
Random question, but should this be an assert that input/output.size() == 1 instead of a check?
Shouldn't this be called only when the arity is already checked by the verifier?