https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125557
--- Comment #9 from Drea Pinski <pinskia at gcc dot gnu.org> --- (In reply to Drea Pinski from comment #8) > (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. Or split paths need to be moved later after phiopt. split paths has definitely been a trouble pass. It was also originally moved from rtl to gimple and when that was done it was moved right after the loop optimizations but before ifcvt. It was moved there because the idea was there could be some cleanups done after the patch was split. But I am not so sure. Anyways see PR 68541, PR 112402, PR 120892. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120892#c3 which talks about maybe removing it. Maybe you can do some benchmarking of removing it? and if your data backs it up; I think proposing to removing it might be a good thing.
