Non-value semantic ops should have stronger verifiers

[stellaraccident]

Currently, in-place ops are defined like:

def Torch_AtenTanh_Op : Torch_Op<"aten.tanh_", [
    IsTrailingUnderscoreInplaceVariant,
    AllowsTypeRefinement
  ]> {
  let summary = "Generated op for `aten::tanh_ : (Tensor) -> (Tensor)`";
  let arguments = (ins
    AnyTorchTensorType:$self
  );
  let results = (outs
    AnyTorchTensorType:$result
  );
  let hasCustomAssemblyFormat = 1;
  let extraClassDefinition = [{
    ParseResult AtenTanh_Op::parse(OpAsmParser &parser, OperationState &result) {
      return parseDefaultTorchOp(parser, result, 1, 1);
    }
    void AtenTanh_Op::print(OpAsmPrinter &printer) {
      printDefaultTorchOp(printer, *this, 1, 1);
    }
  }];
}

The result is that if a !torch.vtensor is inadvertently passed, bad things happen later during lowering. We should tighten up verification by one of:

1. Making the IsTrailingUnderscoreInplaceVariant trait perform stronger verification of the first argument/result type.
2. Teach the torch_ods_gen.py to emit the proper, more constrained types (vs AnyTorchTensorType).

Either would produce the correct result but 2 is more explicit and provides better documentation value. Doing that would require some minor refactoring of the raw_emit_op helper of torch_ods_gen.py so that it tweaks the types if the trait is present.

On the other hand, implementing in 1 would allow us to emit a much more friendly error message, which may help for exotic cases.

[gptsarthak]

I wanted to start contributing to torch-mlir and I think this would be a good beginner issue. I have experience with some very small contributions to upstream MLIR.

From what I understand,

1. This would require us to do a let hasVerifier = 1 in the definition in GeneratedTorchOps.td and create a LogicalResult Tanh_Op::verify() function in, where? I dont know since we are generating the functions, we do not have them defined in TorchOps.cpp. I had this idea looking at Tosa.

2. Assuming that Tanh can only accept Floating point tensors, this would as easy as replacing AnyTorchTensorType with something like Torch_FloatType.

How would you like me to proceed? What else can we do?

[stellaraccident]

It would be great to get a patch for this.

The primary complexity here is that the code in that TD file is generated from the pytorch op registry, so you have to teach torch_ods_gen.py how to do it.

I'm afk but I believe that there is a tablegen type for value tensors vs non value tensors. You probably don't need to further constrain these by dtype.

[gptsarthak]

Have a look at #2519 when you have time. Thank you.

[ramiro050]

Can we close this, @stellaraccident @gptsarthak ?

[stellaraccident]

Yep. Looks fixed