Re: RFC: Another pass_late_combine after pass_reorder_blocks?

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.

Uros.