fix!: Add tensor size check to kernels

[andflo-Arm]

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]

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]

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.

[gunes-arm]

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]

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]

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]

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.

[gunes-arm]

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

[morgolock]

Good work, I think if we solve the duplication problem with const size_t one_channel = 1u; acrosss multiple files this will be ready to be merged

[morgolock]

Great work @andflo-Arm !

The PR looks good to me. I see no obvious problems. I'll let @gunes-arm have a final review at it.