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?
