https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125557
--- Comment #8 from Drea Pinski <pinskia at gcc dot gnu.org> --- (In reply to ktkachov from comment #7) > (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. If split paths is messing it up, then poor_ifcvt_pred in gimple-ssa-split-paths.cc should be tweaked more; I added this function in 2024 (r15-3436-gb2b20b277988ab) to stop split pathes from splitting ifcvtable things because it was doing exactly that. > 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 I posted to PR 125788, my idea on how to do the sinking version of this set. Basically sink should handle more than 2 argument phis and sink from all of incoming bb/edges rather than just the 2. Plus we can think of phiopt as supper charged ifcvt (though needing hoist part of PRE to handle the hoisting parts). The SCC part seems be exactly that of phiopt.
