* [Bug tree-optimization/98726] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
@ 2021-01-18 11:44 ` acoplan at gcc dot gnu.org
2021-01-18 12:25 ` [Bug tree-optimization/98726] [10/11 Regression] " ktkachov at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: acoplan at gcc dot gnu.org @ 2021-01-18 11:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
2021-01-18 11:44 ` [Bug tree-optimization/98726] SVE: " acoplan at gcc dot gnu.org
@ 2021-01-18 12:25 ` ktkachov at gcc dot gnu.org
2021-01-26 12:29 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2021-01-18 12:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
2021-01-18 11:44 ` [Bug tree-optimization/98726] SVE: " acoplan at gcc dot gnu.org
2021-01-18 12:25 ` [Bug tree-optimization/98726] [10/11 Regression] " ktkachov at gcc dot gnu.org
@ 2021-01-26 12:29 ` rguenth at gcc dot gnu.org
2021-01-26 12:30 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-26 12:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (2 preceding siblings ...)
2021-01-26 12:29 ` rguenth at gcc dot gnu.org
@ 2021-01-26 12:30 ` rguenth at gcc dot gnu.org
2021-01-26 12:42 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-26 12:30 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (3 preceding siblings ...)
2021-01-26 12:30 ` rguenth at gcc dot gnu.org
@ 2021-01-26 12:42 ` rguenth at gcc dot gnu.org
2021-01-26 13:27 ` cvs-commit at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-26 12:42 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (4 preceding siblings ...)
2021-01-26 12:42 ` rguenth at gcc dot gnu.org
@ 2021-01-26 13:27 ` cvs-commit at gcc dot gnu.org
2021-01-26 13:30 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-26 13:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (5 preceding siblings ...)
2021-01-26 13:27 ` cvs-commit at gcc dot gnu.org
@ 2021-01-26 13:30 ` rguenth at gcc dot gnu.org
2021-02-19 12:26 ` avieira at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-26 13:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (6 preceding siblings ...)
2021-01-26 13:30 ` rguenth at gcc dot gnu.org
@ 2021-02-19 12:26 ` avieira at gcc dot gnu.org
2021-02-19 12:27 ` avieira at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: avieira at gcc dot gnu.org @ 2021-02-19 12:26 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (7 preceding siblings ...)
2021-02-19 12:26 ` avieira at gcc dot gnu.org
@ 2021-02-19 12:27 ` avieira at gcc dot gnu.org
2021-03-17 15:41 ` rsandifo at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: avieira at gcc dot gnu.org @ 2021-02-19 12:27 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (8 preceding siblings ...)
2021-02-19 12:27 ` avieira at gcc dot gnu.org
@ 2021-03-17 15:41 ` rsandifo at gcc dot gnu.org
2021-03-30 11:04 ` rsandifo at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2021-03-17 15:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (9 preceding siblings ...)
2021-03-17 15:41 ` rsandifo at gcc dot gnu.org
@ 2021-03-30 11:04 ` rsandifo at gcc dot gnu.org
2021-03-31 18:34 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2021-03-30 11:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (10 preceding siblings ...)
2021-03-30 11:04 ` rsandifo at gcc dot gnu.org
@ 2021-03-31 18:34 ` cvs-commit at gcc dot gnu.org
2021-03-31 20:38 ` rsandifo at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-31 18:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (11 preceding siblings ...)
2021-03-31 18:34 ` cvs-commit at gcc dot gnu.org
@ 2021-03-31 20:38 ` rsandifo at gcc dot gnu.org
2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2021-03-31 20:38 UTC (permalink / raw)
To: gcc-bugs
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 ***
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (12 preceding siblings ...)
2021-03-31 20:38 ` rsandifo at gcc dot gnu.org
@ 2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-23 9:10 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984
2021-01-18 11:44 [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
` (13 preceding siblings ...)
2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
@ 2021-04-23 9:10 ` cvs-commit at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-23 9:10 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 16+ messages in thread