[Bug]: When fusing two adjacent ReduceSum operators, a bug occurred in the processing of axes

[ShaneYS]

OpenVINO Version

07ecdf0, Date: Thu Dec 5 01:04:29 2024

Operating System

Ubuntu 20.04 (LTS)

Device used for inference

CPU

Framework

ONNX

Model used

My Custom Model

Issue description

I want to run on cpu with openvino use the following code:

ov::frontend::onnx::FrontEnd::Ptr fe = std::make_shared<ov::frontend::onnx::FrontEnd>();
fe->add_extension(
    std::make_shared<ov::frontend::onnx::OpExtension<ov::op::v0::MyExt1>>(
        "MyExt1", "MyDomain"));
ov::frontend::InputModel::Ptr input_model = fe->load(onnx_path);
std::shared_ptr<ov::Model> model = fe->convert(input_model);

core_.add_extension(std::make_shared<ov::OpExtension<ov::op::v0::MyExt1>>());
compiled_model_ = core_.compile_model(
    model, "CPU", ov::hint::performance_mode(ov::hint::PerformanceMode::LATENCY), ov::inference_num_threads(6));

and bug occurred in core.compile_model:

Part of the structure of my model is shown in the following figure:

In the model, lane_polyline.shape=[1,256,64,16], the axes of p2o.ReduceSum.16 and p2o.ReduceSum.18 is -1, so the shape of p2o.ReduceSum.18's output should be [1, 256].

But in core_.compile_model, may have some op fusion that combines two reducesum into one, and after the fusion, only p2o.ReduceSum.18 is retained, with its axes being [-1, -1], so the shape of p2o.ReduceSum.18's output is [1,256,64], this leads to an error in the shape.

To fix, the axes after fusion should be [-1, -2]. But I don't know which file to modify.

Thanks for your help.

Step-by-step reproduction

No response

Relevant log output

Issue submission checklist

• I'm reporting an issue. It's not a question.
• I checked the problem with the documentation, FAQ, open issues, Stack Overflow, etc., and have not found a solution.
• There is reproducer code and related data files such as images, videos, models, etc.

[ShaneYS]

Hi dear. Another bug has been found here. Do you have any solutions? @SumitkCodes

[SumitkCodes]

@ShaneYS Hi, I had a look at this issue and it seems the problem comes from the fusion of two ReduceSum ops. After fusion, the axes aren’t updated correctly — instead of reducing over two different dimensions, the fused op is reusing the same axis twice (e.g., [-1, -1]), which explains the shape mismatch.

I’m currently digging into the fusion logic to see where the axes should be adjusted (likely to something like [-1, -2]). I’ll continue working on this, but if anyone has suggestions or pointers to the right place in the code, that would be really helpful.

[ShaneYS]

@ShaneYS Hi, I had a look at this issue and it seems the problem comes from the fusion of two ReduceSum ops. After fusion, the axes aren’t updated correctly — instead of reducing over two different dimensions, the fused op is reusing the same axis twice (e.g., [-1, -1]), which explains the shape mismatch.

I’m currently digging into the fusion logic to see where the axes should be adjusted (likely to something like [-1, -2]). I’ll continue working on this, but if anyone has suggestions or pointers to the right place in the code, that would be really helpful.

Maybe I have found the source code, and trying to modify

[SumitkCodes]

@ShaneYS I’ve updated the code could you please review it and let me know if it helps resolve the issue?

[ShaneYS]

@ShaneYS I’ve updated the code could you please review it and let me know if it helps resolve the issue?

Test Pass!
Thanks~

[SumitkCodes]

@ShaneYS Thanks for the Feedback

[ShaneYS]

@ShaneYS I’ve updated the code could you please review it and let me know if it helps resolve the issue?

hi I think the actual data types should be used here, to avoid concat error in some scenarios