On Sun, Dec 14, 2025 at 9:58 PM Andrew Pinski <[email protected]> wrote: > > On Sun, Dec 14, 2025 at 10:20 AM Richard Biener > <[email protected]> wrote: > > > > > > > > > Am 14.12.2025 um 17:30 schrieb Jeff Law <[email protected]>: > > > > > > > > > > > >> On 12/14/25 2:04 AM, Andrew Pinski wrote: > > >> So it turns out creating a forwarder block in some cases causes a > > >> regression. > > >> The rtl ifcvt does like the case were the middle bb does not have a > > >> single predecessor. > > >> So in some cases ifcvt does not happen any more. So the way to fix this > > >> is not to create a forwarder block for those edges which causes out of > > >> ssa to > > >> create a middle bb which has the constant or the copy in it. > > >> I tried to do a simple ifcvt on the gimple level with the last phiopt but > > >> that introduces regressions as then `v += cmp - 43;` is not optimized > > >> and produces an extra subtraction. This is the best workaround I could > > >> come up > > >> with until that is fixed. I filed PR 123116 for that issue. > > >> Bootstrapped and tested on x86_64-linux-gnu. > > >> gcc/ChangeLog: > > >> * tree-cfg.cc (ifconvertable_edge): New function. > > >> (make_forwarders_with_degenerate_phis): Add skip_ifcvtable > > >> argument, > > >> check ifconvertable_edge if skip_ifcvtable is true. > > >> * tree-cfg.h (make_forwarders_with_degenerate_phis): New argument > > >> with default of false. > > >> * tree-cfgcleanup.cc (execute_cleanup_cfg_post_optimizing): Update > > >> argument to make_forwarders_with_degenerate_phis. > > > Not really working today, so not a review. Just a note that this fixes > > > the SFB regressions on the RISC-V port as well. > > > > IIRC we have similar code in path splitting. Can we try creating a helper > > that works for both cases? > > Similar in detecting ifconvertable blocks yes. And in both cases we > start at the "bottom" but the sameness ends there. > > In the path splitting case, by the time we get to the question of > if-convertible, the code had already found an if-then-else diamond > That is: > if/BB3 > / \ > / \ > BB1 BB2 > \ / > \ / > \ / > BB0 > As it was going to duplicate BB0. So the question above would be if > the if-then-else is if-convertible. We don't need to find that BB3 as > it was already detected as being there. > > > While here in degenerate_phis, we have more than 2 edges incoming and > we don't know the common start point. > > we have something more like (most likely more complex with many more > edges into BB0): > BB4 > / \ > / \ > if/BB3 | > / \ | > / \ | > BB1 \ | > \ | | > \ | / > \ | / > \ | / > BB0 > And then we want to reject the edges from BB1/BB3 to BB0. But not the > edge from BB4. So we need to find the common start point this time > around. > > So there is nothing to share between the 2 code even though they > seemingly do the same thing; they handle different cases.
Thanks for checking. Richard. > Thanks, > Andrew > > > > > Richard > > > > > > > > jeff
