https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
Robin Dapp <rdapp at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rdapp at gcc dot gnu.org, | |rguenth at gcc dot gnu.org --- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> --- https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629904.html prevents the wrong code but still leaves us with a redundant negation (and it is not the only missed optimization of that kind): vect_neg_xi_14.4_23 = -vect_xi_13.3_22; vect_res_2.5_24 = .COND_LEN_ADD ({ -1, ... }, vect_res_1.0_17, vect_neg_xi_14.4_23, vect_res_1.0_17, _29, 0); That's because my "hackaround" doesn't recognize a valueized sequence _30 = vect_res_1.0_17 - vect_xi_13.3_22; Of course I could (reverse valueize) recognize that again and convert it to a COND_LEN... but that doesn't seem elegant at all. There must be a simpler way that I'm missing entirely right now. That said, converting the last statement of such a sequence should be sufficient?