Fix DWConv in QNNPACK for aarch32

[joseluisbf-kpsr]

Some function arguments are stored below the stack pointer, that is, in a free memory area. Any call that stores values in the SP (e.g. OS context switch) will corrupt these values after return. We didn't face this problem in Linux, but it raises an _ARMV4_Exception_data_abort_default in RTEMS.

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @jerryzh168

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

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

✅ No Failures

As of commit 9c7d4dd with merge base 3f0931b ():
💚 Looks good so far! There are no failures yet. 💚

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: joseluisbf-kpsr / name: Jose Luis Barros Fernandez (9c7d4dd)

[digantdesai]

Aren't we clobbering d8, unintentionally?
This is done elsewhere too, unfortunately, do you want to take a stab at other kernels too>

[joseluisbf-kpsr]

Aren't we clobbering d8, unintentionally?

No, the r* registers are pushed and then the d*, all above the SP. The reading offsets for r0 and r3 are adjusted accordingly.

This is done elsewhere too, unfortunately, do you want to take a stab at other kernels too>

We didn't find additional issues in our QNNPACK version, in files such as 8x8-aarch64-neon.S and 8x8-aarch64-neon.S: contrary to STR r0, [sp, #-8] (sp is not modified), instructions such as STP d15, d14, [sp, -16] pre-modify sp. (So values are kept safe over the stack pointer.)

[joseluisbf-kpsr]

Dear all,
Could you please review the failure and the patch?
@digantdesai

[github-actions]

Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as Stale.
Feel free to remove the Stale label if you feel this was a mistake.
If you are unable to remove the Stale label please contact a maintainer in order to do so.
If you want the bot to never mark this PR stale again, add the no-stale label.
Stale pull requests will automatically be closed after 30 days of inactivity.

[joseluisbf-kpsr]

Dear jerryzh168, salilsdesai, kimishpatel, digantdesai, and jianyuh

The described bug was confirmed, patched, and the fix was tested and passes all the CI tests.
After months of inactivity, it is now tagged as 'Stalled' and will be closed in 30 days.
I'd appreciate it if you could review and merge this small fix.

[joseluisbf-kpsr]

CC @jerryzh168, @salilsdesai, @kimishpatel, @digantdesai, and @jianyuh

[joseluisbf-kpsr]

CC @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10