aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components.  The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp.  That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
a q-register load/store.

As Richard pointed out in the PR, aarch64_get_separate_components
already checks that the offsets are suitable for a single load, so we
just need to choose a mode in aarch64_reg_save_mode that gives the full
q-register range.  In this patch, we choose V16QImode as an alternative
16-byte "bag-of-bits" mode that doesn't have the artificial range
restrictions imposed on T{I,F,D}mode.

Unlike for GCC 14 we need additional handling in the load/store pair
code as various cases are not expecting to see V16QImode (particularly
the writeback patterns, but also aarch64_gen_load_pair).

gcc/ChangeLog:

	PR target/111677
	* config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
	V16QImode for the full 16-byte FPR saves in the vector PCS case.
	(aarch64_gen_storewb_pair): Handle V16QImode.
	(aarch64_gen_loadwb_pair): Likewise.
	(aarch64_gen_load_pair): Likewise.
	* config/aarch64/aarch64.md (loadwb_pair<TX:mode>_<P:mode>):
	Rename to ...
	(loadwb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
	V16QImode.
	(storewb_pair<TX:mode>_<P:mode>): Rename to ...
	(storewb_pair<TX_V16QI:mode>_<P:mode>): ... this, extending to
	V16QImode.
	* config/aarch64/iterators.md (TX_V16QI): New.

gcc/testsuite/ChangeLog:

	PR target/111677
	* gcc.target/aarch64/torture/pr111677.c: New test.

(cherry picked from commit 2bd8264a131ee1215d3bc6181722f9d30f5569c3)