I'm interested in working on this feature

@Robertwahl, this pr is a good template: #90029 with the reductions specified in ReduceOps.cpp and views in TensorShape.cpp

@eellison, I would like to work on this issue. This will be my first issue. So, I would be grateful if you could give me some guidance on how I should approach this problem.

@eellison is this issue still available?

Yes, still available.

It seems that nobody is doing it, so I would like to start working on that.

From what I understand, we would like to do the following:

1. Add view and reduction tags to aten/src/ATen/native/tags.yaml
2. Go through all the declarations in aten/src/ATen/native/native_functions.yaml and add the relevant tags as follows:
   (a) reduction tag should be added to all operators that accept a reduction argument
   (b) view tag should be added to the operators where none of the arguments are writable. I assume this tag should be consistent with the OpOverload.is_view property.
3. We could add tests to verify this coverage, by iterating over all operators in torch.ops.aten.

Do you agree with that? Is there anything else we should do?

@AlonSardas that sounds close !

(a) reduction tag should be added to all operators that accept a reduction argument

Lets just add the base reductions, not kernels which are parameterized by what type of reduction. See my comment above about the ops in ReduceOps.cpp

I see, and it makes more sense. I still think there are a few finer points worth considering when categorizing operators:

• On reduction: An intuitive definition might be: reduction operations aggregate tensor elements along one or more dimensions, producing an output with fewer dimensions.
  • Many operators in ReduceOps.cpp fit this (e.g. sum, prod, argmax, mean), but cumsum and cumprod don't reduce dimensionality. My assumption was to exclude them. Does that sound reasonable?
  • min and max match the definition but are implemented in TensorCompare.cpp. Should they be tagged as well?
• On view: The list in https://pytorch.org/docs/stable/tensor_view.html seems like a good reference
  • And yet, some operators like reshape, reshape_as and flatten (from TensorShape.cpp) may clone the input and likely shouldn't be tagged as views, agreed?
  • Also, some ops have OpOverload.is_view == True but don’t behave like views (e.g. resolve_neg, resolve_conj, pin_memory). I assume we should exclude those?

If you agree with the points above, I’ll go ahead and open a pull request.

My assumption was to exclude them. Does that sound reasonable

Yes, cumsum and cumprod are considered scans.

And yet, some operators like reshape, reshape_as and flatten

Yea, we are only going to target ops with definitive aliasing reliationships that are CompositeExplicitAutograd as opposed to CompositeImplicitAutograd. See: https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/README.md