aarch64: Rework aarch64_modes_tieable_p [PR112105]

On AArch64, can_change_mode_class and modes_tieable_p are
mostly answering the same questions:

(a) Do two modes have the same layout for the bytes that are
    common to both modes?

(b) Do all valid subregs involving the two modes behave as
    GCC would expect?

(c) Is there at least one register that can hold both modes?

These questions involve no class-dependent tests, and the relationship
is symmetrical.  This means we can do most of the checks in a common
subroutine.

can_change_mode_class is the hook that matters for correctness,
while modes_tieable_p is more for optimisation.  It was therefore
can_change_mode_class that had the more accurate tests.
modes_tieable_p was looser in some ways (e.g. it missed some
big-endian tests) and overly strict in others (it didn't allow
ties between a vector structure mode and the mode of a single lane).
The overly strict part caused a missed combination in the testcase.

I think the can_change_mode_class logic also needed some tweaks,
as described in the changelog.

gcc/
	PR target/112105
	* config/aarch64/aarch64.cc (aarch64_modes_compatible_p): New
	function, with the core logic extracted from...
	(aarch64_can_change_mode_class): ...here.  Extend the previous rules
	to allow changes between partial SVE modes and other modes if
	the other mode is no bigger than an element, and if no other rule
	prevents it.  Use the aarch64_modes_tieable_p handling of
	partial Advanced SIMD structure modes.
	(aarch64_modes_tieable_p): Use aarch64_modes_compatible_p.
	Allow all vector mode ties that it allows.

gcc/testsuite/
	PR target/112105
	* gcc.target/aarch64/pr112105.c: New test.
	* gcc.target/aarch64/sve/pcs/struct_3_128.c: Expect a 32-bit spill
	rather than a 16-bit spill.

0 files changed, 0 insertions, 0 deletions