Re: RFC: Another pass_late_combine after pass_reorder_blocks?

On Thu, Apr 16, 2026 at 1:57 PM Richard Biener <[email protected]> wrote:
>
> On Thu, 16 Apr 2026, Uros Bizjak wrote:
>
> > On Thu, Apr 16, 2026 at 12:58 PM Richard Biener <[email protected]> wrote:
> > >
> > > On Thu, 16 Apr 2026, Uros Bizjak wrote:
> > >
> > > > Hello!
> > > >
> > > > After pass_reorder_blocks, there remain some propagating opportunities
> > > > for late_combine.  Looking at gcc.target/i386/pr90178.c, we get a
> > > > trivial sequence of:
> > > >
> > > > gcc -O2 -mavx -mvzeroupper -m32:
> > > >
> > > > .L5:
> > > >     xorl    %ecx, %ecx
> > > >     ...
> > > >     movl    %ecx, %eax
> > > >     ret
> > > >
> > > > Putting another instance of pass_late_combine after
> > > > pass_reorder_blocks improves the assembly in a non-trivial way:
> > > >
> > > >  @@ -28,10 +28,8 @@
> > > >      cmpl    %edx, %ebx
> > > >      je    .L5
> > > >  .L4:
> > > > -    movl    %eax, %ecx
> > > >      cmpl    %esi, (%eax)
> > > >      jne    .L11
> > > > -    movl    %ecx, %eax
> > > >      popl    %ebx
> > > >      .cfi_remember_state
> > > >      .cfi_restore 3
> > > > @@ -44,17 +42,16 @@
> > > >      .p2align 3
> > > >  .L5:
> > > >      .cfi_restore_state
> > > > -    xorl    %ecx, %ecx
> > > > +    xorl    %eax, %eax
> > > >      popl    %ebx
> > > >      .cfi_restore 3
> > > >      .cfi_def_cfa_offset 8
> > > >      popl    %esi
> > > >      .cfi_restore 6
> > > >      .cfi_def_cfa_offset 4
> > > > -    movl    %ecx, %eax
> > > >      ret
> > > >      .cfi_endproc
> > > >  .LFE0:
> > > >      .size    find_ptr, .-find_ptr
> > > >
> > > > which looks like it is worth putting a new pass here.
> > > >
> > > > A comparison of sizes of default x86_64 linux build shows noticeable
> > > > code size improvement:
> > > >
> > > > $ size vmlinux-old.o vmlinux-new.o
> > > >   text    data     bss     dec     hex filename
> > > > 29432351        4932443  754228 35119022        217dfae vmlinux-old.o
> > > > 29415516        4932443  754228 35102187        2179deb vmlinux-new.o
> > > >
> > > > which shows a code size reduction of 16835 bytes.
> > > >
> > > > Any thoughts?
> > >
> > > Did you check other places to schedule the pass?
> >
> > 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.
>
> Could be a simple regcprop also suffices for the issue at hand?

Hm, putting another pass_cprop_hardreg after pass_reorder_blocks fails
self-test with:

cc1: internal compiler error: pass cprop_hardreg does not support cloning
0x226f97d internal_error(char const*, ...)
       ../../git/gcc/gcc/diagnostic-global-context.cc:787
0xce6a79 opt_pass::clone()
       ../../git/gcc/gcc/passes.cc:90
0xcf8a86 gcc::pass_manager::pass_manager(gcc::context*)
       ./pass-instances.def:554
0xe3a7d7 general_init
       ../../git/gcc/gcc/toplev.cc:1164

Uros.