move to ssize_t and keep the >=0 check for conv and kernel_ops

[JakeStevens]

Summary:
Original code used unsigned for the bounds check with a "redundant" >= 0 check.

This diff restores the >=0 but switches the variable(s) being check to ssize_t

This allows for clean check when:

stride_y * out_y + dilation_y * w_y < padding_y

Previously, we were likely wrapping around and so still succeeding at:

in_y < in_H

because in_y underflows and becomes quite large.

Differential Revision: D96322425

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/18142

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 4 Unrelated Failures

As of commit 51a222a with merge base 6381e58 ():

NEW FAILURES - The following jobs have failed:

• pull / test-binary-size-linux-gcc / linux-job (gh)
  /pytorch/executorch/kernels/portable/cpu/op_convolution.cpp:175:41: error: comparison of integer expressions of different signedness: ‘ssize_t’ {aka ‘long int’} and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
• pull / unittest-editable / macos / macos-job (gh)
  export/tests/test_target_recipes.py::TestTargetRecipes::test_linear_model

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Build Presets / windows (pybind) / build (gh) (trunk failure)
• Build Presets / windows (windows) / build (gh) (trunk failure)
  The process 'C:\Program Files\Git\cmd\git.exe' failed with exit code 1
• pull / unittest / windows / windows-job (gh) (trunk failure)
• pull / unittest-editable / windows / windows-job (gh) (trunk failure)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[meta-codesync]

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D96322425.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.