[Bug tree-optimization/122297] Wrong code due to bad VEC_EXTRACT index when LEN_LOAD falls back to QI mode

[jchrist at linux dot ibm.com]

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

--- Comment #4 from jchrist at linux dot ibm.com ---
(In reply to Richard Biener from comment #3)
> Created attachment 62573 [details]
> patch
> 
> Can you test this?  With it we generate
> 
>   <bb 16> [local count: 81467477]:
>   # vect_last_29.19_72 = PHI <vect_last_29.19_71(12)>
>   # adjusted_loop_len_96 = PHI <adjusted_loop_len_69(12)>
>   _73 = adjusted_loop_len_96 + 1;
>   _74 = _73 >> 2;
>   _75 = _74 + 18446744073709551615;
>   _76 = .VEC_EXTRACT (vect_last_29.19_72, _75);
> 
> should be double-checked on other len-vectorized targets.  I wonder why
> this didn't show up as issue on RISC-V?  Are we maybe not using byte-based
> lens everywhere?

No, we are not.  See the modified version of nodump-vecextract-1.c where we use
element-sized len.  We only fall back to byte-based lens if we actually use
.LEN_LOAD and the backend only supportes this on QI mode.  If we .VEC_EXTRACT
from a vector that never was influenced by a .LEN_LOAD, we track element-based.
 That was exactly the point where I could not figure out how to fix this and
decided to create this PR to ask for help.

I tested your patch.  As I suspected, it fixes the reproducer, but now the
modified nodump-vecextract-1.c crashes.