https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123322
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
Status|UNCONFIRMED |NEW
CC| |rdapp at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2025-12-29
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So in GCC 15 it was not optimized in ce1, when we get to ce2 things have been
cleaned up considerably and we get a conversion via cond_zero_arith, generating
the clean code we want.
In GCC 16, the costing code was improved to more accurately cost the
conditional jump. That's enough to flip the decision for handling multiple set
blocks during ce1 to be profitable. And I'd largely agree -- it is
profitable, it's just not as profitable as the cond_zero_arith path that would
be discovered in ce2 had we not done the multiple-set conversion during ce1.
I've seen one other similar case, though I don't think it was triggered by the
costing change. Just a general issue with the multiple set code triggering
during ce1 when we would have been better off waiting for various cleanups that
in turn would have enabled a cond_zero_arith sequence during ce2.
