[BUG] Discrepancy Between OpenCL and Host

[EJainDev]

The host API uses size_t for all numerical input parameters but the OpenCL API uses int. I noticed when seeing what issue #558 was referring to. Some problems with this:

1. That's a major issue on 64-bit platforms. Do we want 4-byte or 8-byte offsets, strides, and lengths?
2. Unsigned/signed mismatch. Do we want negative offset or negative strides or only positive?

[CNugteren]

Indeed, this could be an issue in theory. But will it be an issue in practice? For example, for the m, n, and k input dimensions of GEMM I don't think 2^31 or more is realistic. Perhaps for other parameters it is in some edge cases? Not sure.

[EJainDev]

I think for clarity the front end should be changed to int as well to not provide false “promises” to users.

As for strides/offsets, should the API support negative and positive or only positive because this behavior is also different across the front and back end.

EDIT:
I tried doing a PR but its more difficult than it seems because of the different uses of size_t. Front end can be covered by generator scripts but the backend (src/routines/*) would then become incompatible. Something to do for the future.

[CNugteren]

front end should be changed to int

That would be a big API update, let's not break the API if it isn't really necessary.

I would suggest a much simpler solution: keep everything as is but return an error if the user supplies arguments that are too large to fit in 32-bit. Perhaps there are actually already such checks, also on the strides and offsets regarding negative values?