[ghstack-poisoned]

…itions"

[ghstack-poisoned]

…itions"

[ghstack-poisoned]

…itions"

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…itions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]

…positions"

This PR adds a new alias key for composite kernels, bringing the total count to 3. Composite kernels should be registered to this new key under the following conditions:
- The operator itself is functional (no alias annotations)
- The decomposition calls into ops that *do* have alias annotations (either mutations or views)
- The operator has a derivative formula

This alias key is similar to the `CompositeExplicitAutograd` alias key, except that the `Lazy` and `XLA` runtime keys aren't included in it (and any other future "functional" backends). That's because functional -> non-functional decompositions are not useful / kinda bad for functional backends, especially once they start using the functionalization pass (at best they introduce unnecessary overhead, at worst they can potentially cause an infinite loop with the functionalization pass).

Current key name in the PR is `CompositeExplicitAutogradWithMutations`, but I'm open to any better ideas on the name for the new key - I guess I could also use this opportunity to rename the existing composite alias keys if we think it's really worth it, although I was hoping to not have to change the existing key names :)

Other ideas:
- `CompositeExplicitAutogradNonFunctional` (better captures the fact that functional -> view decomps are also used here)
- `CompositeExplicitAutogradFunctionalToNonFunctional` (better captures the fact that the op itself should be functional, although probably way too wordy)


Note 1: in theory we could add a corresponding `CompositeImplicitAutogradWithMutations` key, but there isn't really a use case for it - it doesn't matter for functionalization, because `CompositeImplicitAutograd` kernels will *always* decompose before entering the functionalization pass.

Note 2: I was a little conflicted about what to do with mutation -> mutation decompositions (like an inplace op that decomposes to its out= variant). Semantically, I don't think it really makes sense for them to go in this key, because it doesn't matter if functional backends run them (it's only bad to *replace* a functional op with a non-functional one). We have a bunch of codegen'd `functional -> out=` and `inplace -> out=` kernels though, which I updated to get registered to the new `CompositeExplicitAutogradWithMutations` key. The `functional -> out=` kernels should definitely get registered to this key, but the `inplace -> out=` kernels probably shouldn't. But it's kind of harmless to register `inplace -> out=` kernels to the new key, and teasing that out would require adding a bunch of extra logic.


A good example of a kernel that fits this category is the  `cummax` kernel, which looks like this (and cummax has a derivative formula defined):
```
std::tuple<Tensor, Tensor> cummax(const Tensor& self, int64_t dim) {
  auto values = at::empty(self.sizes(), self.options());
  auto indices = at::empty(self.sizes(), self.options().dtype(at::kLong));
  at::cummax_out(values, indices, self, dim);
  return std::make_tuple(values, indices);
}
```

**Have all of the relevant kernels been switched over to the new key in this PR?**
No. The only ones I switched were:
- all of the codegen'd kernels
- all of the (recently added) `view_copy.out` kernels in native_functions.yaml
- A handful of one-off kernels that I noticed in native_functions.yaml

But there are probably a bunch more - I'm going to switch more over as part of integrating functionalization with LTC/XLA.



Differential Revision: [D35953393](https://our.internmc.facebook.com/intern/diff/D35953393)

[ghstack-poisoned]