chore: remove aten.full decomposition

[peri044]

Description

aten.full is being decomposed into aten.full_like + additional operators as follows

%empty : [num_users=1] = call_function[target=torch.ops.aten.empty.memory_format](args = ([%sym_size_int, %add_2],), kwargs = {device: cpu, pin_memory: False})
%_to_copy : [num_users=1] = call_function[target=torch.ops.aten._to_copy.default](args = (%empty,), kwargs = {dtype: torch.float32, layout: torch.strided, device: cuda:0})
%as_strided : [num_users=1] = call_function[target=torch.ops.aten.as_strided.default](args = (%_to_copy, [%sym_size_int, %add_2], [%add_2, 1]), kwargs = {})
%full_like : [num_users=1] = call_function[target=torch.ops.aten.full_like.default](args = (%as_strided, -3.4028234663852886e+38), kwargs = {pin_memory: False})

I'm not sure if this is needed. There's additional failures due to this because _to_copy has capability validators which get invalidated and you see "Conversion for _to_copy node" is not supported errors.

In torch decompositions, seems like they have removed it https://github.com/pytorch/pytorch/blob/main/torch/_decomp/__init__.py

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[peri044]

So if we removeaten.full from decomposition list, I assume it won't get decomposed to full_like then? In that case-

1. Should we have a converter or decomposition for aten.full-> torch.empty + torch.fill_

We should have a converter for aten.full directly I think. Is there a need for the decomposition you mentioned ?

[apbose]

I think the previous comment got deleted. I had another question-
So if we removeaten.full from decomposition list, I assume it won't get decomposed to full_like then? In that case-

1. Should we have a converter or decomposition for aten.full-> torch.empty + torch.fill_
2. Also would we need a converter/decomposition/evaluator for full_like- https://github.com/pytorch/TensorRT/pull/2917/files unless it is encountered in the decomposition above.

Regarding the decomposition, don't know, may be we could create a converter, but a decomposition would come first in my head when I think of aten.full. Why would a converter be preferred? Would it lead to the same errors you mentioned in the PR description if we did decomposition from torch-tensorrt side?

[zewenli98]

From my understanding, conversion and decomposition are similar from the view of TRT since TRT would do some optimizations, like fusion to ILayers, if we implement a converter for aten.full that's similar to the decomposed ops. So having a converter for aten.full is fine for me. Correct me if I'm wrong.

[apbose]

Ok I can implement a converter for full then. Meanwhile I will also try experimenting if doing decomposition from torch TRT side (and not using the torch decomposition) would lead to the same error as mentioned in the PR description).
This PR looks good then. TODO would be to implement the converter.

[peri044]

Ok I can implement a converter for full then. Meanwhile I will also try experimenting if doing decomposition from torch TRT side (and not using the torch decomposition) would lead to the same error as mentioned in the PR description). This PR looks good then. TODO would be to implement the converter.

@apbose
My thought process is full_like is an extension of full (atleast when it comes to TRT implementation which will use IFillLayer). Correct me if you think otherwise.
If you think you can implement a torch-trt decomposition for aten.full in a simpler way and won't encounter the errors/extra ops, that's fine. Else, this can be a straightforward implementation for a converter.

[zewenli98]

LGTM