[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-7934-g1b5f74e8be4dd7abe5624ff60adceff19ca71bda
Author: Richard Sandiford 
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): 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 target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Testing a patch.  See also PR98726.

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-01-14

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Alex Coplan  ---
Adding -fno-tree-forwprop gives us an ICE in LRA instead:

$ aarch64-elf-gcc -c pr97141.c -O3 -march=armv8.2-a+sve -fno-tree-forwprop

during RTL pass: reload
pr97141.c: In function 'g':
pr97141.c:8:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
8 | }
  | ^
0xc08d23 lra_constraints(bool)
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:5061
0xbeff49 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2329
0xba2af8 do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5802
0xba2af8 execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Originally noticed this LRA ICE with the related testcase:

int a;
void b() {
  a = 0;
  for (; a != -24; a = (short)a - 3) {
short *c;
*c |= 0 < b;
  }
}

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[akrl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from akrl at gcc dot gnu.org ---
Hi all,

this is so far my understanding of what is going on here:

While in expand the vector builder is trying to build to determine elt number 3
of a vector of POLY_INT_CST.

To do that the step has to be computed, therefore rtx_vector_builder::step is
calling wi::sub to compute the difference between elt1 and elt2.

wi::sub (in wide-int.h:2508) is making use of WIDE_INT_REF_FOR so we end up in
decompose where we have no handling for poly_int.

I'm a little puzzled because I'm not sure where in this stack would be correct
to add the poly_int handling.

decompose is returning a wi::storage_ref that AFAIU has no poly support.

It might be easier to handle the poly subtraction in rtx_vector_builder::step
before entering into wide-int specific code?

  Andrea

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3