Re: RFC: Another pass_late_combine after pass_reorder_blocks?

On Thu, Apr 16, 2026 at 2:35 PM Uros Bizjak <[email protected]> wrote:
>
> On Thu, Apr 16, 2026 at 2:29 PM Uros Bizjak <[email protected]> wrote:
> >
> > On Thu, Apr 16, 2026 at 1:57 PM Richard Biener <[email protected]> wrote:
> >
> > > > I was interested to exercise opportunities, exposed by bbro pass (as
> > > > mentioned in [1]), so the natural place to put the new pass is after
> > > > bbro pass:
> > > >
> > > > On x86_32, IRA zeroes %ecx, which is later copied to %eax in the
> > > > terminal basic block:
> > > >
> > > >    12: NOTE_INSN_BASIC_BLOCK 3
> > > >     7: cx:SI=0
> > > >       REG_EQUAL 0
> > > >    45: pc=L36
> > > >    ...
> > > >    36: L36:
> > > >    39: NOTE_INSN_BASIC_BLOCK 7
> > > >    37: ax:SI=cx:SI
> > > >    38: use ax:SI
> > > >
> > > > This sequence is reordered in bbro pass to:
> > > >
> > > >    28: L28:
> > > >    12: NOTE_INSN_BASIC_BLOCK 7
> > > >    69: {cx:SI=0;clobber flags:CC;}
> > > >       REG_UNUSED flags:CC
> > > >    71: ax:SI=cx:SI
> > > >       REG_DEAD cx:SI
> > > >    72: use ax:SI
> > > >    73: NOTE_INSN_EPILOGUE_BEG
> > > >    74: bx:SI=[sp:SI++]
> > > >       REG_CFA_ADJUST_CFA sp:SI=sp:SI+0x4
> > > >       REG_CFA_RESTORE bx:SI
> > > >    75: si:SI=[sp:SI++]
> > > >       REG_CFA_ADJUST_CFA sp:SI=sp:SI+0x4
> > > >       REG_CFA_RESTORE si:SI
> > > >    76: simple_return
> > >
> > > Ah, so maybe we can have a late combine entry that can be invoked
> > > iff BB reorder does any path duplication only?  On GIMPLE we
> > > increasingly invoke pass workers directly from other passes
> > > in such case, VN even has a mode to operate on small portions
> > > of the CFG.
> >
> > Please also note that with the i386 testcase, even before bbro pass
> > there is in _.c.350r.rtl_dce:
> >
> >    25: L25:
> >    18: NOTE_INSN_BASIC_BLOCK 5
> >    19: cx:SI=ax:SI
> >    20: flags:CCZ=cmp([ax:SI],si:SI)
> >    21: pc={(flags:CCZ==0)?L36:pc}
> >       REG_DEAD flags:CCZ
> >       REG_BR_PROB 59055801
> >    22: NOTE_INSN_BASIC_BLOCK 6
> >    23: {dx:SI=dx:SI+0x1;clobber flags:CC;}
> >       REG_UNUSED flags:CC
> >    24: {ax:SI=ax:SI+0x4;clobber flags:CC;}
> >       REG_UNUSED flags:CC
> >    26: flags:CCZ=cmp(bx:SI,dx:SI)
> >    27: pc={(flags:CCZ!=0)?L25:pc}
> >       REG_DEAD flags:CCZ
> >       REG_BR_PROB 1014686025
> >    47: NOTE_INSN_BASIC_BLOCK 7
> >    48: pc=L28
> >    49: barrier
> >    36: L36:
> >    39: NOTE_INSN_BASIC_BLOCK 8
> >    37: ax:SI=cx:SI
> >       REG_DEAD cx:SI
> >    38: use ax:SI
> >
> > (insn 19) and (insn 37) are also detected by pass_late_combine as
> > redundant. So, the pass should run even if BB reorder doesn't
> > duplicate paths to optimize some opportunities, exposed by previous
> > passes.
>
> Hm, no. When - fno-reorder-blocks -fno-reorder-blocks-and-partition
> options are added to compile options, the newly added
> pass_late_combine does nothing. So, there indeed are new opportunities
> only when BB reorders blocks (duplicates paths?).

I have filled enhancement PR124901 [1] and summarized all discussion there.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124901

Uros.