stor-layout, aarch64: Express SRA intrinsics with RTL codes

This patch expresses the intrinsics for the SRA and RSRA instructions with
standard RTL codes rather than relying on UNSPECs.
These instructions perform a vector shift right plus accumulate with an
optional rounding constant addition for the RSRA variant.
There are a number of interesting points:

* The scalar-in-SIMD-registers variant for DImode SRA e.g. ssra d0, d1, #N
is left using the UNSPECs. Expressing it as a DImode plus+shift led to all
kinds of trouble as it started matching the existing define_insns for
"add x0, x0, asr #N" instructions and adding the SRA form as an extra
alternative required a significant amount of deduplication of iterators and
things still didn't work out well. I decided not to tackle that case in
this patch. It can be attempted later.

* For the RSRA variants that add a rounding constant (1 << (shift-1)) the
addition is notionally performed in a wider mode than the input types so that
overflow is handled properly. In RTL this can be represented with an appropriate
extend operation followed by a truncate back to the original modes.
However for 128-bit input modes such as V4SI we don't have appropriate modes
defined for this widening i.e. we'd need a V4DI mode to represent the
intermediate widened result.  This patch defines such modes for
V16HI,V8SI,V4DI,V2TI. These will come handy in the future too as we have
more Advanced SIMD instruction that have similar intermediate widening
semantics.

* The above new modes led to a problem with stor-layout.cc. The new modes only
exist for the sake of the RTL optimisers understanding the semantics of the
instruction but are not indended to be moved to and from register or memory,
assigned to types, used as TYPE_MODE or participate in auto-vectorisation.
This is expressed in aarch64 by aarch64_classify_vector_mode returning zero
for these new modes. However, the code in stor-layout.cc:<mode_for_vector>
explicitly doesn't check this when picking a TYPE_MODE due to modes being made
potentially available later through target switching (PR38240).
This led to these modes being picked as TYPE_MODE for declarations such as:
typedef int16_t vnx8hi __attribute__((vector_size (32))) when 256-bit
fixed-length SVE modes are available and vector_type_mode later struggling
to rectify this.
This issue is addressed with the new target hook
TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P that is intended to check if a
vector mode can be used in any legal target attribute configuration of the
port, as opposed to the existing TARGET_VECTOR_MODE_SUPPORTED_P that checks
only the initial target configuration. This allows a simple adjustment in
stor-layout.cc that still disqualifies these limited modes early on while
allowing consideration of modes that can be turned on in the future with
target attributes.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

	* config/aarch64/aarch64-modes.def (V16HI, V8SI, V4DI, V2TI): New modes.
	* config/aarch64/aarch64-protos.h (aarch64_const_vec_rnd_cst_p):
	Declare prototype.
	(aarch64_const_vec_rsra_rnd_imm_p): Likewise.
	* config/aarch64/aarch64-simd.md (*aarch64_simd_sra<mode>): Rename to...
	(aarch64_<sra_op>sra_n<mode>_insn): ... This.
	(aarch64_<sra_op>rsra_n<mode>_insn): New define_insn.
	(aarch64_<sra_op>sra_n<mode>): New define_expand.
	(aarch64_<sra_op>rsra_n<mode>): Likewise.
	(aarch64_<sur>sra_n<mode>): Rename to...
	(aarch64_<sur>sra_ndi): ... This.
	* config/aarch64/aarch64.cc (aarch64_classify_vector_mode): Add
	any_target_p argument.
	(aarch64_extract_vec_duplicate_wide_int): Define.
	(aarch64_const_vec_rsra_rnd_imm_p): Likewise.
	(aarch64_const_vec_rnd_cst_p): Likewise.
	(aarch64_vector_mode_supported_any_target_p): Likewise.
	(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Likewise.
	* config/aarch64/iterators.md (UNSPEC_SRSRA, UNSPEC_URSRA): Delete.
	(VSRA): Adjust for the above.
	(sur): Likewise.
	(V2XWIDE): New mode_attr.
	(vec_or_offset): Likewise.
	(SHIFTEXTEND): Likewise.
	* config/aarch64/predicates.md (aarch64_simd_rsra_rnd_imm_vec): New
	predicate.
	* doc/tm.texi (TARGET_VECTOR_MODE_SUPPORTED_P): Adjust description to
	clarify that it applies to current target options.
	(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Document.
	* doc/tm.texi.in: Regenerate.
	* stor-layout.cc (mode_for_vector): Check
	vector_mode_supported_any_target_p when iterating through vector modes.
	* target.def (TARGET_VECTOR_MODE_SUPPORTED_P): Adjust description to
	clarify that it applies to current target options.
	(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Define.

1 files changed, 15 insertions, 1 deletions

diff --git a/gcc/target.def b/gcc/target.def
index cda6c51..7d68429 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -3491,13 +3491,27 @@ code in @file{optabs.cc}.",
    for further details.  */
 DEFHOOK
 (vector_mode_supported_p,
- "Define this to return nonzero if the port is prepared to handle\n\
+ "Define this to return nonzero if the current target is prepared to handle\n\
 insns involving vector mode @var{mode}.  At the very least, it\n\
 must have move patterns for this mode.",
  bool, (machine_mode mode),
  hook_bool_mode_false)
 
 DEFHOOK
+(vector_mode_supported_any_target_p,
+ "Define this to return nonzero if the port is prepared to handle\n\
+insns involving vector mode @var{mode} in any target configuration.\n\
+Returning @var{true} means that the mode can be used as the @samp{TYPE_MODE}\n\
+for vector types.\n\
+\n\
+The default version of this hook returns true.  The final mode assigned to\n\
+@samp{TYPE_MODE} will also be checked against\n\
+@code{TARGET_VECTOR_MODE_SUPPORTED_P} to take target configuration into\n\
+account.",
+ bool, (machine_mode mode),
+ hook_bool_mode_true)
+
+DEFHOOK
 (compatible_vector_types_p,
  "Return true if there is no target-specific reason for treating\n\
 vector types @var{type1} and @var{type2} as distinct types.  The caller\n\