fix!: Add tensor size check to kernels by andflo-Arm · Pull Request #1268 · ARM-software/ComputeLibrary

andflo-Arm · 2026-03-12T16:17:09Z

The size check implies a tensor size restriction to 2^31-1 bytes. Kernel
configurations larger than that will no longer validate.

Resolves: COMPMID-8697

Change-Id: I54f73ade5cb4a0d34d831505d83d1d7ef526b5db

gunes-arm · 2026-03-12T16:19:55Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

andflo-Arm · 2026-03-13T08:44:35Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

Done. The exclamation mark serves the purpose of conveying breaking changes.

src/core/CL/kernels/CLArgMinMaxLayerKernel.cpp

src/cpu/kernels/CpuFloorKernel.cpp

gunes-arm · 2026-03-13T16:30:24Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

Done. The exclamation mark serves the purpose of conveying breaking changes.

Are we adding a feature here, or are we fixing something?

andflo-Arm · 2026-03-16T07:58:06Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

Done. The exclamation mark serves the purpose of conveying breaking changes.

Are we adding a feature here, or are we fixing something?

I have thought a little about it, and I'm not sure what to call it. I'm hesitant to call it a fix because we're not fixing broken functionality (bug) -- we are adding something that simply didn't exist before. On the other hand it's also a bit of a stretch to call it a feature because the validation doesn't bring any new usable functionality. But I do lean more towards feat because it's still something new that is added.

gunes-arm · 2026-03-16T12:55:41Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

Done. The exclamation mark serves the purpose of conveying breaking changes.

Are we adding a feature here, or are we fixing something?

I have thought a little about it, and I'm not sure what to call it. I'm hesitant to call it a fix because we're not fixing broken functionality (bug) -- we are adding something that simply didn't exist before. On the other hand it's also a bit of a stretch to call it a feature because the validation doesn't bring any new usable functionality. But I do lean more towards feat because it's still something new that is added.

Here is my perspective, let me know what you think: I think we're fixing a bug because in the validate() calls, we should have been returning false for certain combinations. Those combinations weren't supported, but we were saying we were supporting them.

And, this is not a feature because we're not adding any new functionality. We're merely fixing a bug and possibly limiting our support set as a result of this conservative checks.

andflo-Arm · 2026-03-16T15:55:17Z

I didn't look yet, but it'd be useful anyways. Could you explain why this is a breaking change in the description? And, I suppose we need to add smth like BREAKING CHANGE (?) somewhere

Done. The exclamation mark serves the purpose of conveying breaking changes.

Are we adding a feature here, or are we fixing something?

I have thought a little about it, and I'm not sure what to call it. I'm hesitant to call it a fix because we're not fixing broken functionality (bug) -- we are adding something that simply didn't exist before. On the other hand it's also a bit of a stretch to call it a feature because the validation doesn't bring any new usable functionality. But I do lean more towards feat because it's still something new that is added.

Here is my perspective, let me know what you think: I think we're fixing a bug because in the validate() calls, we should have been returning false for certain combinations. Those combinations weren't supported, but we were saying we were supporting them.

And, this is not a feature because we're not adding any new functionality. We're merely fixing a bug and possibly limiting our support set as a result of this conservative checks.

Yes it also makes sense. I think my reasoning was that if the library is used as intended, will something then go wrong? From that perspective, no, it's not a bug. But if validate defines what is intended, then yes, it's a bug because as you say, validate lied for certain combinations. I think this case is a bit muddy because validation by nature only makes a difference when the user tries to color outside the lines :) I'm happy to change to fix.

src/core/CL/kernels/CLArgMinMaxLayerKernel.cpp

gunes-arm

I've only been able to check until NEGather. I'll continue.

src/core/CL/kernels/CLBatchToSpaceLayerKernel.cpp

src/core/CL/kernels/CLGatherKernel.cpp

src/core/CL/kernels/CLGenerateProposalsLayerKernel.cpp

src/core/CL/kernels/CLPriorBoxLayerKernel.cpp

src/core/CL/kernels/CLSpaceToBatchLayerKernel.cpp

gunes-arm · 2026-03-17T10:35:25Z

src/core/CPP/kernels/CPPUpsampleKernel.cpp

@@ -44,6 +45,7 @@ bool CPPUpsampleKernel::is_parallelisable() const
 void CPPUpsampleKernel::configure(const ITensor *input, ITensor *output, const PadStrideInfo &info)


We should add validate() calls to some kernels, especially in CPU and call their validate functions from the callers. But, I think it should be a separate ticket. Can you create a list of kernels, such as this one, that doesn't have validate() function and create a ticket for this?

The size check implies a tensor size restriction to 2^31-1 bytes. Kernel configurations larger than that will no longer validate. Resolves: COMPMID-8697 Signed-off-by: Andreas Flöjt <andreas.floejt@arm.com> Change-Id: I54f73ade5cb4a0d34d831505d83d1d7ef526b5db

gunes-arm · 2026-03-17T12:49:42Z

src/core/NEON/kernels/NEPriorBoxLayerKernel.cpp

-        ARM_COMPUTE_RETURN_ERROR_ON_MISMATCHING_DATA_TYPES(input1, output);
-    }
+    // There's no default configuration, so we expect that output is initialized.
+    ARM_COMPUTE_ERROR_ON(output->total_size() == 0);


As before, we shouldn't throw, we should return a Status.

gunes-arm · 2026-03-17T12:55:20Z

src/core/NEON/kernels/NEReorgLayerKernel.cpp

    ARM_COMPUTE_RETURN_ERROR_ON_MSG((input->tensor_shape()[idx_height] % stride) != 0,
                                    "The height of the input tensor must be a multiple of stride");

+    TensorShape output_shape = misc::shape_calculator::compute_reorg_output_shape(*input, stride);


gunes-arm · 2026-03-17T13:02:45Z

src/core/NEON/kernels/NESpaceToDepthLayerKernel.cpp

    }
+    else
+    {
+        const TensorShape output_shape = misc::shape_calculator::compute_space_to_depth_shape(input, block_shape);


I think it'd be good to check this in if part, too.

gunes-arm · 2026-03-17T13:03:57Z

src/cpu/kernels/CpuAddMulAddKernel.cpp

@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2023, 2025 Arm Limited.
+ * Copyright (c) 2023, 2025, 2026 Arm Limited.


gunes-arm · 2026-03-17T13:10:01Z

src/cpu/kernels/CpuDynamicGemmKernel.cpp

 {
    ARM_COMPUTE_TRACE_EVENT(ARM_COMPUTE_PROF_CAT_CPU, ARM_COMPUTE_PROF_LVL_CPU, "CpuDynamicGemmKernel::validate");
    ARM_COMPUTE_RETURN_ERROR_ON_NULLPTR(a, b, c, d);
+    ARM_COMPUTE_RETURN_ERROR_ON_SIZE_UNSUPPORTED(a, b, c, d);


These shapes can be dynamic, so it shouldn't be checked here.

gunes-arm · 2026-03-17T13:22:03Z

src/cpu/kernels/CpuElementwiseUnaryKernel.cpp

            ARM_COMPUTE_ERROR("ElementWiseUnary operation not supported");
    }
+
+    const auto output_shape = TensorShape::broadcast_shape(src.tensor_shape());


This is a unary operator, so output shape will be equal to src shape. This is doing the same thing I suppose.

Also, we should validate the shapes only when tensor is not dynamic shape.

gunes-arm · 2026-03-17T14:06:18Z

src/gpu/cl/kernels/ClPool2dKernel.cpp

        if (indices->total_size() != 0)
        {
-            TensorInfo idx_info(TensorInfo(compute_pool_shape(*src, pool_info), 1, DataType::U32));
+            const auto idx_info = TensorInfo(TensorInfo(compute_pool_shape(*src, pool_info), 1, DataType::U32));


Why do we need nested constructors here?

gunes-arm · 2026-03-17T14:20:39Z

src/runtime/CL/functions/CLCropResize.cpp

-    TensorInfo temp_info;
-    ARM_COMPUTE_RETURN_ON_ERROR(CLCrop::validate(input->clone().get(), &temp_info, {0, 0}, {1, 1},
+    auto temp_info = output->clone();
+    temp_info->set_tensor_shape(TensorShape(input->dimension(0), crop_size.x, crop_size.y));


What is this for?

andflo-Arm force-pushed the pr/tensor-size-checks branch from 493638b to 773dc2f Compare March 13, 2026 08:41

gunes-arm reviewed Mar 13, 2026

View reviewed changes

src/core/CL/kernels/CLArgMinMaxLayerKernel.cpp Show resolved Hide resolved

gunes-arm reviewed Mar 13, 2026

View reviewed changes

src/cpu/kernels/CpuFloorKernel.cpp Outdated Show resolved Hide resolved

andflo-Arm force-pushed the pr/tensor-size-checks branch from 773dc2f to f6ceb31 Compare March 16, 2026 16:07

andflo-Arm changed the title ~~feat!: Add tensor size check to kernels~~ fix!: Add tensor size check to kernels Mar 16, 2026

gunes-arm reviewed Mar 16, 2026

View reviewed changes

src/core/CL/kernels/CLArgMinMaxLayerKernel.cpp Show resolved Hide resolved

gunes-arm requested changes Mar 17, 2026

View reviewed changes

andflo-Arm force-pushed the pr/tensor-size-checks branch from f6ceb31 to b8c4667 Compare March 17, 2026 14:11

gunes-arm requested changes Mar 17, 2026

View reviewed changes

		@@ -44,6 +45,7 @@ bool CPPUpsampleKernel::is_parallelisable() const
		void CPPUpsampleKernel::configure(const ITensor input, ITensor output, const PadStrideInfo &info)

Conversation

andflo-Arm commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gunes-arm commented Mar 12, 2026

Uh oh!

andflo-Arm commented Mar 13, 2026

Uh oh!

Uh oh!

Uh oh!

gunes-arm commented Mar 13, 2026

Uh oh!

andflo-Arm commented Mar 16, 2026

Uh oh!

gunes-arm commented Mar 16, 2026

Uh oh!

andflo-Arm commented Mar 16, 2026

Uh oh!

Uh oh!

gunes-arm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

andflo-Arm commented Mar 12, 2026 •

edited

Loading