https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 13 Jan 2025, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 > > --- Comment #19 from Kewen Lin <linkw at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #18) > > I think this misses a :s on the negate_expr_p, but I'm not sure this > > "works", so eventually && single_use (@1), given the original expression > > doesn't go away. > > Thanks for the hints! I verified that :s isn't supported there, it seems > still > a good thing to make this matching if there are multiple uses but all are > under > the same form (rhs_code and operand index are the same) since the original > expression are able to be eliminated? Should we introduce a stricter check for > this like below? You are not allowed to look at immediate uses during folding, so no. But yes, this is basically the old issue that we have no folding pass that works "globally" when avoiding to create new semi-redundant sub-expressions. As you say, when we can create the same sub-expression for all uses we can CSE it again. So the current way to handle this is to give up conservatively. Basically we hope to catch all cases in the first forwprop pass, before FRE runs. On GENERIC there are no "CSE"d sub-expressions visible (OK, SAVE_EXPR, but we never handle that).
