[Bug tree-optimization/98726] New: aarch64: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[Bug tree-optimization/98726] New: aarch64: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

            Bug ID: 98726
           Summary: aarch64: tree check: expected integer_cst, have
                    poly_int_cst in to_wide, at tree.h:5984
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat test.c
int a, c;
char b;
int d() {
  a = 0;
  for (; a <= 21; a = (short)a + 1)
    b &= c;
}
$ aarch64-elf-gcc -c test.c -O3 -march=armv8.2-a+sve
during GIMPLE pass: forwprop
test.c: In function 'd':
test.c:3:5: internal compiler error: tree check: expected integer_cst, have
poly_int_cst in to_wide, at tree.h:5984
    3 | int d() {
      |     ^
0x1161f66 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
        /home/alecop01/toolchain/src/gcc/gcc/tree.c:9812
0x7393c1 tree_check(tree_node const*, char const*, int, char const*, tree_code)
        /home/alecop01/toolchain/src/gcc/gcc/tree.h:3594
0x7393c1 wi::to_wide(tree_node const*)
        /home/alecop01/toolchain/src/gcc/gcc/tree.h:5984
0x1177e1d vector_cst_int_elt(tree_node const*, unsigned int)
        /home/alecop01/toolchain/src/gcc/gcc/tree.c:11104
0x11935a3 vector_cst_elt(tree_node const*, unsigned int)
        /home/alecop01/toolchain/src/gcc/gcc/tree.c:11131
0xa35b48 const_binop(tree_code, tree_node*, tree_node*, tree_node*)
        /home/alecop01/toolchain/src/gcc/gcc/fold-const.c:1644
0x1484144 gimple_resimplify2
        /home/alecop01/toolchain/src/gcc/gcc/gimple-match-head.c:276
0x14b3ca2 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
        /home/alecop01/toolchain/src/gcc/gcc/gimple-match-head.c:957
0xa9c5d1 fold_stmt_1
        /home/alecop01/toolchain/src/gcc/gcc/gimple-fold.c:6016
0xa9ef9b fold_stmt(gimple_stmt_iterator*, tree_node* (*)(tree_node*))
        /home/alecop01/toolchain/src/gcc/gcc/gimple-fold.c:6254
0xf73a2a execute
        /home/alecop01/toolchain/src/gcc/gcc/tree-ssa-forwprop.c:3108
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/98726] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
      Known to fail|                            |11.0
           Keywords|                            |ice-checking,
                   |                            |ice-on-valid-code
             Target|                            |aarch64
            Summary|aarch64: tree check:        |SVE: tree check: expected
                   |expected integer_cst, have  |integer_cst, have
                   |poly_int_cst in to_wide, at |poly_int_cst in to_wide, at
                   |tree.h:5984                 |tree.h:5984

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |9.3.1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-01-18
      Known to fail|                            |10.2.1
     Ever confirmed|0                           |1
   Target Milestone|11.0                        |10.3
                 CC|                            |ktkachov at gcc dot gnu.org
           Priority|P3                          |P2
            Summary|SVE: tree check: expected   |[10/11 Regression] SVE:
                   |integer_cst, have           |tree check: expected
                   |poly_int_cst in to_wide, at |integer_cst, have
                   |tree.h:5984                 |poly_int_cst in to_wide, at
                   |                            |tree.h:5984

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eh, we can't even _dump_ those VECTOR_CST:

#0  internal_error (gmsgid=0x29cb490 "tree check: %s, have %s in %s, at %s:%d")
    at ../../src/trunk/gcc/diagnostic.c:1804
#1  0x00000000017d00ea in tree_check_failed (
    node=<poly_int_cst 0x7ffff6f25300>, 
    file=0x2858ad0 "../../src/trunk/gcc/tree.h", line=5984, 
    function=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide")
    at ../../src/trunk/gcc/tree.c:9812
#2  0x0000000000ad994d in tree_check (__t=<poly_int_cst 0x7ffff6f25300>, 
    __f=0x2858ad0 "../../src/trunk/gcc/tree.h", __l=5984, 
    __g=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide", 
    __c=INTEGER_CST) at ../../src/trunk/gcc/tree.h:3594
#3  0x0000000000b56c27 in wi::to_wide (t=<poly_int_cst 0x7ffff6f25300>)
    at ../../src/trunk/gcc/tree.h:5984
#4  0x00000000017d75b2 in vector_cst_int_elt (t=<vector_cst 0x7ffff6f2e050>, 
    i=3) at ../../src/trunk/gcc/tree.c:11104
#5  0x00000000017d7798 in vector_cst_elt (t=<vector_cst 0x7ffff6f2e050>, i=3)
    at ../../src/trunk/gcc/tree.c:11131
#6  0x00000000014e0e2c in dump_generic_node (pp=0x3754e00, 
    node=<vector_cst 0x7ffff6f2e050>, spc=0, flags=2112, is_stmt=false)
    at ../../src/trunk/gcc/tree-pretty-print.c:2112

11101     /* Otherwise work out the value from the last two encoded elements. 
*/
11102     tree v1 = VECTOR_CST_ENCODED_ELT (t, final_i - npatterns);
11103     tree v2 = VECTOR_CST_ENCODED_ELT (t, final_i);
11104     wide_int diff = wi::to_wide (v2) - wi::to_wide (v1);
(gdb) p v1
$5 = <poly_int_cst 0x7ffff6f25300>
(gdb) p v2
$6 = <poly_int_cst 0x7ffff6f25320>

now if such VECTOR_CST is well-formed (well ...?), then with using
poly_wide_int in vector_cst_int_elt we at least get to RTL expansion where
we ICE like

#0  fancy_abort (file=0x28dd290 "../../src/trunk/gcc/rtl.h", line=2296, 
    function=0x28e84a0 <wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose(long*, unsigned int, std::pair<rtx_def*, machine_mode>
const&)::__FUNCTION__> "decompose") at ../../src/trunk/gcc/diagnostic.c:1884
#1  0x0000000000e17546 in wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose (precision=32, x=...) at ../../src/trunk/gcc/rtl.h:2296
#2  0x0000000000e45617 in wide_int_ref_storage<false,
false>::wide_int_ref_storage<std::pair<rtx_def*, machine_mode> >
(this=0x7fffffffc5a0, x=..., 
    precision=32) at ../../src/trunk/gcc/wide-int.h:1034
#3  0x0000000000e427e7 in generic_wide_int<wide_int_ref_storage<false, false>
>::generic_wide_int<std::pair<rtx_def*, machine_mode> > (this=0x7fffffffc5a0, 
    x=..., precision=32) at ../../src/trunk/gcc/wide-int.h:790
#4  0x0000000000e405be in wi::sub<std::pair<rtx_def*, machine_mode>,
std::pair<rtx_def*, machine_mode> > (x=..., y=...) at
../../src/trunk/gcc/wide-int.h:2512
#5  0x000000000132743f in rtx_vector_builder::step (this=0x7fffffffc7a0, 
    elt1=0x7ffff6f2f0c0, elt2=0x7ffff6f2f0e0)
    at ../../src/trunk/gcc/rtx-vector-builder.h:122
#6  0x000000000132795e in vector_builder<rtx_def*, machine_mode,
rtx_vector_builder>::elt (this=0x7fffffffc7a0, i=3)
    at ../../src/trunk/gcc/vector-builder.h:254
#7  0x0000000001327051 in rtx_vector_builder::build (this=0x7fffffffc7a0)
    at ../../src/trunk/gcc/rtx-vector-builder.c:73
#8  0x0000000000eb109a in const_vector_from_tree (
    exp=<vector_cst 0x7ffff6f2e078>) at ../../src/trunk/gcc/expr.c:12763

Richard - are POLY_INT_CST element VECTOR_CST well-formed?  It seems
they are introduced during vectorization but there they are simple
like { POLY_INT_CST [4, 4], ... } but then FRE4 produces

Value numbering stmt = _48 = vect_cst__46 + { 0, 1, 2, ... };
Match-and-simplified vect_cst__46 + { 0, 1, 2, ... } to { POLY_INT_CST [16,
16], POLY_INT_CST [17, 16], POLY_INT_CST [18, 16], ... }

and things start to go downhill.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 50056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50056&action=edit
patch to make dumping not ICE

The attached avoids ICEing during dumping (it seems there's no reason to export
the function in the first place)

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So looks like induction vectorization is the culprit here but I also guess
that's actually supported?

-fdisable-tree-fre4 -fdisable-tree-fre5 -fdisable-tree-dom3

makes the testcase compile since we only retain the basic VECTOR_CSTs that
appear to be supported?

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a

commit r11-6912-g4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Jan 26 13:32:27 2021 +0100

    middle-end/98726 - fix VECTOR_CST element access

    This fixes VECTOR_CST element access with POLY_INT elements and
    allows to produce dump files of the PR98726 testcase without
    ICEing.

    2021-01-26  Richard Biener  <rguenther@suse.de>

            PR middle-end/98726
            * tree.h (vector_cst_int_elt): Remove.
            * tree.c (vector_cst_int_elt): Use poly_wide_int for computations,
            make static.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
RTL expansion ICE remains.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #7 from avieira at gcc dot gnu.org ---
I'm looking at this and I have a feeling there is a disconnect on how some
passes define VECTOR_CST and how the expand pass handles it.

So the problem here seems to lie with the V4SImode VECTOR_CST at expand time:

{ POLY_INT_CST [24, 16], POLY_INT_CST [25, 16], POLY_INT_CST [26, 16],
POLY_INT_CST [27, 16] }

The problem seems to be that const_vector_from_tree only adds the first
VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN and this has:
 VECTOR_CST_NPATTERNS: 1
 VECTOR_CST_NELTS_PER_PATTERN: 3

The mode however dictates 4 elements (constant-sized V4SImode). So
rtx_vector_builder::build adds the first three and then tries to derive the
fourth (even though it is right there), at this point it fails as it uses
wi::sub and that doesn't seem to work for POLY_INT's.

This is where I started investigating how it should work. I looked at cases of
actual patterns involving POLY_INT's, like:
{ POLY_INT_CST [8, 8], POLY_INT_CST [9, 8], POLY_INT_CST [10, 8], ... }

These have a VLA mode, so because there is no constant element number
rtx_vector_builder::build uses the 'encoded_nelts' which are again the
VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN elements and never needs to
derive a step.

I also looked at how a VECTOR_CST with N random integers is built and there it
seems VECTOR_CST_NPATTERNS * VECTOR_CST_NELTS_PER_PATTERN describe the full
length of the VECTOR_CST.

At this point I don't know whether the construction of the VECTOR_CST is wrong,
or whether the building is, I just know there seems to be a disconnect.

There are a variety of things that we could do:
1) Change how the VECTOR_CST is being created so that VECTOR_CST_NPATTERNS *
VECTOR_CST_NELTS_PER_PATTERN == GET_MODE_NUNITS (m_mode).is_constant (&nelts)
for constant sized modes.
2) Change const_vector_from_tree to check whether a POLY_INT VECTOR_CST has a
constant sized mode, construct the RTVEC_ELT itself and use
rtx_vector_builder::build(rtvec v)
3) Teach rtx_vector_builder::step and apply_step how to deal with POLY_INT's

Out of all 2 is my favourite. Though we should aim to look at 1 too. Because I
have seen a big descrepancy in how these VECTOR_CST's are formed, I've also
seen:
{1, 1, 1, 1, 1, 1, 1, 1} being described using:
VECTOR_CST_NPATTERNS: 1
VECTOR_CST_NELTS_PER_PATTERN: 3

Which is unnecessary... {1, ...} would have sufficed with both NPATTERNS and
NELTS_PER_PATTERN set to 1 for instance, or make it so they multiply to 8.
Unless we want this flexibility?

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[avieira at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #8 from avieira at gcc dot gnu.org ---
Also at some point we should figure out why the vectorizer is generating this
much code for this example, where I think it should be able to optimized it to:

a = 22;
b &= c;

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
I think we should do a variation on (3): use poly-int subtraction
in rtx_vector_builder::step but force the returned value to a constant
using to_constant ().  The justification is that the encoding
requires the step to be constant, but doesn't require the individual
elements to be.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|avieira at gcc dot gnu.org         |rsandifo at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
The RTL side is the same problem as PR97141.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:1b5f74e8be4dd7abe5624ff60adceff19ca71bda

commit r11-7934-g1b5f74e8be4dd7abe5624ff60adceff19ca71bda
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Mar 31 19:34:00 2021 +0100

    Handle CONST_POLY_INTs in CONST_VECTORs [PR97141, PR98726]

    This PR is caused by POLY_INT_CSTs being (necessarily) valid
    in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
    in RTL CONST_VECTORs.  I can't tell/remember how deliberate
    that was, but I'm guessing not very.  In particular,
    valid_for_const_vector_p was added to guard against symbolic
    constants rather than CONST_POLY_INTs.

    I did briefly consider whether we should maintain the current
    status anyway.  However, that would then require a way of
    constructing variable-length vectors from individiual elements
    if, say, we have:

       { [2, 2], [3, 2], [4, 2], ⦠}

    So I'm chalking this up to an oversight.  I think the intention
    (and certainly the natural thing) is to have the same rules for
    both trees and RTL.

    The SVE CONST_VECTOR code should already be set up to handle
    CONST_POLY_INTs.  However, we need to add support for Advanced SIMD
    CONST_VECTORs that happen to contain SVE-based values.  The patch does
    that by expanding such CONST_VECTORs in the same way as variable vectors.

    gcc/
            PR rtl-optimization/97141
            PR rtl-optimization/98726
            * emit-rtl.c (valid_for_const_vector_p): Return true for
            CONST_POLY_INT_P.
            * rtx-vector-builder.h (rtx_vector_builder::step): Return a
            poly_wide_int instead of a wide_int.
            (rtx_vector_builder::apply_set): Take a poly_wide_int instead
            of a wide_int.
            * rtx-vector-builder.c (rtx_vector_builder::apply_set): Likewise.
            * config/aarch64/aarch64.c (aarch64_legitimate_constant_p): Return
            false for CONST_VECTORs that cannot be forced to memory.
            * config/aarch64/aarch64-simd.md (mov<mode>): If a CONST_VECTOR
            is too complex to force to memory, build it up from individual
            elements instead.

    gcc/testsuite/
            PR rtl-optimization/97141
            PR rtl-optimization/98726
            * gcc.c-torture/compile/pr97141.c: New test.
            * gcc.c-torture/compile/pr98726.c: Likewise.
            * gcc.target/aarch64/sve/pr97141.c: Likewise.
            * gcc.target/aarch64/sve/pr98726.c: Likewise.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|ASSIGNED                    |RESOLVED

--- Comment #12 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed on trunk.  Treating as a dup for backports.

*** This bug has been marked as a duplicate of bug 97141 ***

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:8849e4a94550ffc9a564c105f0cefed5f42b3a7d

commit r10-9752-g8849e4a94550ffc9a564c105f0cefed5f42b3a7d
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Apr 23 10:09:40 2021 +0100

    middle-end/98726 - fix VECTOR_CST element access

    This fixes VECTOR_CST element access with POLY_INT elements and
    allows to produce dump files of the PR98726 testcase without
    ICEing.

    2021-04-23  Richard Biener  <rguenther@suse.de>

            PR middle-end/98726
            * tree.h (vector_cst_int_elt): Remove.
            * tree.c (vector_cst_int_elt): Use poly_wide_int for computations,
            make static.

    (cherry picked from commit 4b59dbb5d6759e43bfa23161a8d3feb9ae969e1a)

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:dc9233a4f65a67ca280903d60d57c5fd5d95303e

commit r10-9753-gdc9233a4f65a67ca280903d60d57c5fd5d95303e
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Fri Apr 23 10:09:41 2021 +0100

    Handle CONST_POLY_INTs in CONST_VECTORs [PR97141, PR98726]

    This PR is caused by POLY_INT_CSTs being (necessarily) valid
    in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
    in RTL CONST_VECTORs.  I can't tell/remember how deliberate
    that was, but I'm guessing not very.  In particular,
    valid_for_const_vector_p was added to guard against symbolic
    constants rather than CONST_POLY_INTs.

    I did briefly consider whether we should maintain the current
    status anyway.  However, that would then require a way of
    constructing variable-length vectors from individiual elements
    if, say, we have:

       { [2, 2], [3, 2], [4, 2], ⦠}

    So I'm chalking this up to an oversight.  I think the intention
    (and certainly the natural thing) is to have the same rules for
    both trees and RTL.

    The SVE CONST_VECTOR code should already be set up to handle
    CONST_POLY_INTs.  However, we need to add support for Advanced SIMD
    CONST_VECTORs that happen to contain SVE-based values.  The patch does
    that by expanding such CONST_VECTORs in the same way as variable vectors.

    gcc/
            PR rtl-optimization/97141
            PR rtl-optimization/98726
            * emit-rtl.c (valid_for_const_vector_p): Return true for
            CONST_POLY_INT_P.
            * rtx-vector-builder.h (rtx_vector_builder::step): Return a
            poly_wide_int instead of a wide_int.
            (rtx_vector_builder::apply_set): Take a poly_wide_int instead
            of a wide_int.
            * rtx-vector-builder.c (rtx_vector_builder::apply_set): Likewise.
            * config/aarch64/aarch64.c (aarch64_legitimate_constant_p): Return
            false for CONST_VECTORs that cannot be forced to memory.
            * config/aarch64/aarch64-simd.md (mov<mode>): If a CONST_VECTOR
            is too complex to force to memory, build it up from individual
            elements instead.

    gcc/testsuite/
            PR rtl-optimization/97141
            PR rtl-optimization/98726
            * gcc.c-torture/compile/pr97141.c: New test.
            * gcc.c-torture/compile/pr98726.c: Likewise.
            * gcc.target/aarch64/sve/pr97141.c: Likewise.
            * gcc.target/aarch64/sve/pr98726.c: Likewise.

    (cherry picked from commit 1b5f74e8be4dd7abe5624ff60adceff19ca71bda)