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.

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

src/core/CL/kernels/CLArgMinMaxLayerKernel.cpp

gunes-arm

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

gunes-arm · 2026-03-16T18:44:34Z

src/core/CL/kernels/CLBatchToSpaceLayerKernel.cpp

    }
+    else
+    {
+        // Ignored; dynamic block is deprecated.


What does this mean?

There are two implementations of this kernel: one with a statically known block shape and this one with a dynamic block shape from a tensor. The dynamic block shape implementation doesn't have a default configured shape so there's nothing to validate when output is not configured. I'd even argue that we could assert that output->total_size() != 0, but I don't know. Regardless, validate and configure for dynamic block shape were supposed to be removed in 23.08 according to their deprecation note in the API doc. To avoid problems from doing so now, I instead left a comment that this else case is deliberately ignored specifically because it's deprecated anyway.

(The same for NEBatchToSpaceLayerKernel.)

gunes-arm · 2026-03-16T19:26:59Z

src/core/CL/kernels/CLGatherKernel.cpp

+    const size_t one_channel = 1u;
+    ARM_COMPUTE_RETURN_ERROR_ON(input->num_channels() != one_channel);
+
+    TensorShape output_shape = arm_compute::misc::shape_calculator::compute_gather_shape(


gunes-arm · 2026-03-16T19:28:34Z

src/core/CL/kernels/CLGenerateProposalsLayerKernel.cpp

    ARM_COMPUTE_RETURN_ERROR_ON(anchors->num_dimensions() > 2);
+    size_t            feature_height = info.feat_height();
+    size_t            feature_width  = info.feat_width();
+    size_t            num_anchors    = anchors->dimension(1);


all three can be const

gunes-arm · 2026-03-17T08:52:38Z

src/core/CL/kernels/CLPriorBoxLayerKernel.cpp

-        ARM_COMPUTE_RETURN_ERROR_ON(output->dimension(1) != 2);
-    }
+    // There is no default configure, so we expect output to be initialized.
+    ARM_COMPUTE_ERROR_ON(output->total_size() == 0);


We shouldn't throw anything from validate(). The user should get a Status when they input invalid output tensor info.

gunes-arm · 2026-03-17T10:14:49Z

src/core/CL/kernels/CLSpaceToBatchLayerKernel.cpp

    ARM_COMPUTE_RETURN_ERROR_ON(input->num_dimensions() > 4);
    ARM_COMPUTE_RETURN_ERROR_ON(block_shape_x < 1 || block_shape_y < 1);

+    TensorShape expected_output_shape = misc::shape_calculator::compute_space_to_batch_shape(


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?

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

		@@ -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!

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