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?
