https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122297
Bug ID: 122297
Summary: Wrong code due to bad VEC_EXTRACT index when LEN_LOAD
falls back to QI mode
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jchrist at linux dot ibm.com
Target Milestone: ---
Created attachment 62568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62568&action=edit
Reproducer test case
Hi,
when vectorizing attached code on s390x, we generate wrong code. The reason is
that we treat the iv as number of bytes, but later use it in a VEC_EXTRACT on a
V4SI vector.
While looking into this, I found that vect_get_loop_len is called with a factor
of 1, but finds an rgl with a factor of 4. Now, on s390x, we use the
bias_adjusted_ctrl-path which in this case simply returns the control. I am
somehow unsure if we should instead in this case return something like
`rgl->bias_adjusted_ctrl / rgl->factor` or if I am at the wrong place with
this.
Note that this only happens if actual loads are involved. I have another
testcase (variant of nodump-vecextract-1.c) that does not use LEN_LOAD and
therefore never transforms the iv into number of bytes. In that case, both the
factor given to vect_get_loop_len and the factor in the found rgl are 1.
