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.
Note this triggers:
Tests that now fail, but worked before (2 tests):
gcc: gcc.target/sh/pr51244-11.c scan-assembler-not subc|and|bra
gcc: gcc.target/sh/pr51244-19.c scan-assembler-not movt
The pr51244-11 test is marginally bogus as it's supposed to be testing
if we're using the zero-offset-branch support. Essentially the SH4 has
a fast path for a conditional branch with a zero offset; so we want to
use that instead of certain other sequences.
As it turns out we're not using zero-offset-branches at all and the
change above allows us to if-convert a sequence that was previously
branchy and looks profitable to me. Of course that triggers the
!subc|and|bra scan-assembler failure. It might just be best to xfail
given the state of the test.
pr51244-19 is also a case where we're if-converting now when we weren't
before and it looks profitable to me as well. That one likely could be
addressed with a -fno-if-conversion or something similar.
I'm not chasing either of these given the updated code looks better to
me. I've reset baselines in my tester so they're expected failures
going forward.
jeff
