Re: RFC: Another pass_late_combine after pass_reorder_blocks?

On Fri, Apr 17, 2026 at 1:49 PM Richard Biener <[email protected]> wrote:
>
> On Fri, 17 Apr 2026, Uros Bizjak wrote:
>
> > On Thu, Apr 16, 2026 at 1:57 PM Richard Biener <[email protected]> wrote:
> >
> > > 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?
> >
> > FTR: Adding *another* pass_cprop_hardreg after pass_reorder_blocks
> > also shows some code size improvements with x86_64 default linux
> > kernel:
> >
> > $ size *.o
> >    text    data     bss     dec     hex filename
> > 29378531        4929075  744820 35052426        216db8a vmlinux-add.o
> > 29382751        4929075  744820 35056646        216ec06 vmlinux-baseline.o
> > 29384459        4929075  744820 35058354        216f2b2 vmlinux-moved.o
> >
> > where vmlinux-baseline.o is compiled with vanilla GCC, vmlinux-add.o
> > is compiled with additional pass_cprop_hardreg after
> > pass_reorder_blocks, and vmlinux-moved.o is compiled with
> > pass_cprop_hardreg moved from its current position to after
> > pass_reorder_blocks.
> >
> > The code size changes are:
> >
> > vmlinux-moved.o: +1708 bytes
> > vmlinux-add.o  : -4220 bytes
> >
> > So, it looks there is some benefit by adding another
> > pass_cprop_hardreg after pass_reorder_blocks.
>
> Yes, clearly the path duplication performed by reorder-blocks creates
> optimization opportunities, in general CSE opportunities (including
> simple copy propatation) and combine opportunities since it can
> form new EBBs.  I think at least cprop-hardreg is worth pursuing,
> though eventually cselib can handle that as well and might be suited
> to work on select EBBs?

I'd leave combine opportunities alone, because (as shown in the PR),
combine-like pass can recombine intentionally split instructions back
into non-optimal ones. But propagating hardregs is always a win, as it
eliminates unnecessary register-to-register moves.

Uros.