https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760
--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (In reply to Robin Dapp from comment #2) > 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? Yeah. That's what I want to point it out. Your patch will disable the optimization I made in GIMPLE_FOLD for COND_LEN_xxx. I am not sure how to fix it, I think we need Richi's help for that since he knows the GIMPLE FOLD stuff the best.
