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,
Andrew
>
> Richard
>
> >
> > jeff
