https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122297
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to jchrist from comment #4) > (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. Hum. Can you point me to where we fall back to byte-based len?
