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?
