RFC: Another pass_late_combine after pass_reorder_blocks?

[Richard Biener]

On Fri, 17 Apr 2026, Uros Bizjak wrote:

> On Thu, Apr 16, 2026 at 1:57 PM Richard Biener <rguenther@suse.de> 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?