This doesn’t really fit with the data model of PyTorch, in theory it would be perfectly legal for me to register an op that did something like:
def my_custom_op(x):
if x.size(1) % 2:
return x.to(torch.float32)
else:
return x.to(torch.float16)
That is a contrived example, but there are ops that change dtypes based on non-tensor args and whose behavior changes based on global amp modes. The source of truth is the implementation, and I wouldn’t want to change the source of truth to some external file we needed to keep in sync with the implementations. That sounds like a maintenance burden.
We solved this same problem in a more general with meta functions, fake tensors, and symints. I could write a meta function for the above example that queried x.size(1) % 2 (guarding in the case of symint) and provided accurate metadata.
I don’t think ONNX should try to manually build such a yaml file on the side either. You should just automatically generate it based on OpInfo testing. OpInfo tests contain example inputs for each operator, including all the dtypes those ops support. You could just write a script to scrape the data you need out of that. If there are some coverage gaps in the OpInfo inputs, you could also write a script to just exhaustively try every dtype on every op – using OpInfo inputs as a starting place.