https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125557
--- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to Drea Pinski from comment #6) > Note the final ifcvt part needs to have a decent cost model; right now your > patches don't have one and it is not obvious if it is always better > especially on targets which don't have a cmov (or cmov like instruction; e.g > riscv's czero.nez/czero.eqz). We need much more time on figuring that part > out. Either we should improve ifcvt or have something in the last phiopt. > Having it as part of sink breaks what sink is doing. Yeah, that makes sense. With your latest patches at https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720191.html we do get the right factoring on Snappy. RTL ifcvt then does the final ifcvt but only at -O2. At -O3 -fsplit-paths messes up the basic blocks. It can still be handled by RTL ifcvt though (which does have the target knowldge about cmovs and the appropriate costing), I'll have a look at that. So for this particular Snappy I think we don't need the sink work if your patches go in, though a simpler version of my sinking patches could still be valuable for other cases
