Check for matching CONST_VECTOR encodings [PR99929]

PR99929 is one of those “how did we get away with this for so long”
bugs: the equality routines weren't checking whether two variable-length
CONST_VECTORs had the same encoding.  This meant that:

   { 1, 0, 0, 0, 0, 0, ... }

would appear to be equal to:

   { 1, 0, 1, 0, 1, 0, ... }

since both are represented using the elements { 1, 0 }.

gcc/
	PR rtl-optimization/99929
	* rtl.h (same_vector_encodings_p): New function.
	* cse.c (exp_equiv_p): Check that CONST_VECTORs have the same encoding.
	* cselib.c (rtx_equal_for_cselib_1): Likewise.
	* jump.c (rtx_renumbered_equal_p): Likewise.
	* lra-constraints.c (operands_match_p): Likewise.
	* reload.c (operands_match_p): Likewise.
	* rtl.c (rtx_equal_p_cb, rtx_equal_p): Likewise.

gcc/testsuite/
	* gcc.target/aarch64/sve/pr99929_1.c: New file.
	* gcc.target/aarch64/sve/pr99929_2.c: Likewise.

1 files changed, 17 insertions, 0 deletions

diff --git a/gcc/rtl.h b/gcc/rtl.h
index a392721..398d745 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -3087,6 +3087,23 @@ vec_series_p (const_rtx x, rtx *base_out, rtx *step_out)
   return const_vec_series_p (x, base_out, step_out);
 }
 
+/* Return true if CONST_VECTORs X and Y, which are known to have the same mode,
+   also have the same encoding.  This means that they are equal whenever their
+   operands are equal.  */
+
+inline bool
+same_vector_encodings_p (const_rtx x, const_rtx y)
+{
+  /* Don't be fussy about the encoding of constant-length vectors,
+     since XVECEXP (X, 0) and XVECEXP (Y, 0) list all the elements anyway.  */
+  if (poly_uint64 (CONST_VECTOR_NUNITS (x)).is_constant ())
+    return true;
+
+  return (CONST_VECTOR_NPATTERNS (x) == CONST_VECTOR_NPATTERNS (y)
+	  && (CONST_VECTOR_NELTS_PER_PATTERN (x)
+	      == CONST_VECTOR_NELTS_PER_PATTERN (y)));
+}
+
 /* Return the unpromoted (outer) mode of SUBREG_PROMOTED_VAR_P subreg X.  */
 
 inline scalar_int_mode