Add dtype functions for ops that take dtype from 1st operand

[li-plus]

This PR finished the task 1 of #1807.

The three crashing cases (ElementwiseClampModule_basic, IouOfModule_basic, NormalizeModule_basic) are related to clamp op whose dtype function accepts optional non-tensor arguments.

def aten〇clamp〡dtype(self_rank_dtype: Tuple[int, int], min: Optional[Union[int, float]] = None, max: Optional[Union[int, float]] = None) -> int:
    ...

They are crashing on the assert below. @ramiro050 do you have any idea for this?

torch-mlir/lib/Dialect/Torch/Transforms/ReifyAbstractInterpCalculationsUtils.cpp

Lines 180 to 186 in 63945a2

	// If the operand is NoneType, then we just need to derefine it to the
	// optional type in the function signature.
	if (operandType.isa<Torch::NoneType>()) {
	assert(desiredType.isa<Torch::OptionalType>() &&
	"Don't expect library functions to have NoneType parameters");
	return b.create<DerefineOp>(loc, desiredType, operand).getResult();
	}

[ramiro050]

This seems to be an issue with our importer. If you look at the MLIR snippet generated for clamp, the type Optional[Union[int, float]] is being converted to !torch.union<int, float, none> instead of !torch.optional<union<int, float>>.

[ramiro050]

Actually, the type Union[int, float, None] is being created by torch.jit.script. I think it should simply be a matter of widening the types allowed by the assert to include union types that have None as one of the contained types

[li-plus]

Actually, the type Union[int, float, None] is being created by torch.jit.script. I think it should simply be a matter of widening the types allowed by the assert to include union types that have None as one of the contained types

Thanks! This is exactly the case. I fixed it by derefining these optional scalars to type !torch.union<int, float, none>.

Once #1990 is merged, I will switch to meta tensors and resolve the WIP status.

[li-plus]

@ramiro050 This PR is ready to merge. Would you review it? Thanks.

[ramiro050]

Awesome!