Codegen doesn't support ops with multiple output tensors (e.g. `slogdet`)

[miladm]

Codegen doesn't support ops with multiple output tensors (e.g. slogdet). Below is the codegen results as well as the error reported. This issue blocked full codegen integration of slogdet in #3576.

CC @JackCaoG @wonjoolee95 @wconstab

Issue 1:

error: no matching function for call to 'std::vector<c10::intrusive_ptr<torch_xla::XLATensor> >::push_back(torch_xla::XLATensor)'

Looks like torch_xla::XLATensor::Create(torch::lazy::Value(node, i), *common_device) creates a pointer while the vector requires torch_xla::XLATensor.

Issue 2:
Why is there a :: in front of the function return type?

---

In XLANativeFunctions.cpp:

    ::std::tuple<at::Tensor,at::Tensor> XLANativeFunctions::slogdet(const at::Tensor & self) {
        
        XLA_FN_COUNTER("xla::");
        auto common_device = torch_xla::bridge::GetXlaDevice(self);
        TORCH_INTERNAL_ASSERT(common_device);
        
        torch_xla::XLATensorPtr lazy_self = torch_xla::bridge::GetXlaTensorOrCreateForWrappedNumber(self, *common_device);
        torch::lazy::NodePtr node = torch::lazy::ReuseNode<Slogdet>(lazy_self->GetIrValue());
        if (!node) {
            
            auto shapes = torch::lazy::compute_shape_slogdet(self);
            TORCH_INTERNAL_ASSERT(shapes.size() == 2);
            if(torch::lazy::symbolicShapeEnabled()){
                std::vector<torch::jit::IValue> inputs = { self };
                char* schema_str = "aten::slogdet(Tensor self) -> (Tensor sign, Tensor logabsdet)";
                applySymbolicShapesOnLT(schema_str, inputs, shapes);
            }
        
            node = torch::lazy::MakeNode<Slogdet>(lazy_self->GetIrValue(), std::move(shapes));
            CacheNode(node);
        }
        
        std::vector<torch_xla::XLATensorPtr> lazy_tensors;
        for (int i = 0; i < 2; i++) {
            lazy_tensors.push_back(torch_xla::XLATensor::Create(torch::lazy::Value(node, i), *common_device));
        }
        auto result = torch::lazy::TupleAtenFromLtcTensors<2>(lazy_tensors);
        return result;
    };

[miladm]

To unblock #3576, I have commented out slogdet implementation to merge in logdet only. Once this issue is resolved, I will uncomment the codegen segment as a separate PR.

[wconstab]

@miladm

Issue 2:
Why is there a :: in front of the function return type?

Are you referring to this return type?

::std::tupleat::Tensor,at::Tensor

That type is generated by the non-LTC portions of the torchgen infra. I can look deeper into why, but, it seems correct to me to absolutely qualify the std::tuple. Is it causing an issue?

[JackCaoG]

::std::tupleat::Tensor should be fine, we can revisit if it becomes an issue.

[wconstab]

I tried adding slogdet to the ts_native_functions.yaml and found that codegen generates the following code:

        std::vector<LazyTensorPtr> lazy_tensors;
        for (int i = 0; i < 2; i++) {
            lazy_tensors.push_back(torch::lazy::LazyTensor::Create(torch::lazy::Value(node, i), *common_device));
        }

In our case, the LazyTensor::Create function does return LazyTensorPtr objects, which is also what the vector expects.

I wonder if the expectations on what type is returned from ::Create function are getting ambiguous or changing?
https://github.com/pytorch/pytorch/blob/master/torch/csrc/lazy/core/tensor.h#L58
https://github.com/pytorch/xla/blob/master/torch_xla/csrc/tensor.h#L33

I'm not sure how we got ourselves to diverge but would it be possible to align? I think we changed our 'Create' to return a pointer around the time we refactored a bunch of stuff and made LazyTensor an intrusive_ptr_target.

If not, we can unblock you by changing our codegen to let you customize more stuff, but I'd prefer not to if possible.

cc @Krovatkin @JackCaoG

[JackCaoG]

I think it is because I asked you to make LTC to use LazyTensorPtr instead of LazyTensor class so I can inherit XLATensor from LazyTensor. I am working on phase3 of LTC migration and part of that change includes adapting upstream LazyTensor class(inheritance). As a quick workaround I can also make PyTorch/XLA pass XLATensor as Ptr which should unblock this change.

[miladm]

Catching up on this thread.
@JackCaoG did your workaround get integrated into master already? If so, I can take a second pass at adding this op to codegen.

[JackCaoG]

I have not work on this, will try to figure something out next week.

[miladm]

Let me know if I can help.

[zpcore]

Probably also related to ops with tensorlist input. I tried to use codegen for stack but didn't see any auto generated modifications. Does this mean codegen is not supported for tensorlist input/output?