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?

src/core/NEON/kernels/NEPriorBoxLayerKernel.cpp

src/core/NEON/kernels/NEReorgLayerKernel.cpp

src/core/NEON/kernels/NESpaceToDepthLayerKernel.cpp

src/cpu/kernels/CpuAddMulAddKernel.cpp

src/cpu/kernels/CpuDynamicGemmKernel.cpp

src/cpu/kernels/CpuElementwiseUnaryKernel.cpp

src/gpu/cl/kernels/ClPool2dKernel.cpp

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?

When I made ClCropKernel.cpp expect its output tensor to be configured due to lack of a default config, tests started failing despite having output shapes in the test cases. It turned out that the kernel never got the output shapes because this function validation always passed an empty TensorInfo.

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

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

andflo-Arm force-pushed the pr/tensor-size-checks branch from b8c4667 to eae088c Compare March 18, 2026 12:53

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

gunes-arm Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gunes-arm Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

andflo-Arm Mar 18, 2026

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