On Wed, Nov 26, 2025 at 03:11:40PM -0700, Jeff Law wrote: > > > On 11/26/25 1:11 PM, Dimitar Dimitrov wrote: > > Starting with r16-4438-ga93f80feeef744, the edges started to be sorted > > in ascending order. Thus the most likely branches were deprioritized > > instead of optimized to fallthroughs. > > > > Fix by restoring the sorting order prior to r16-4438-ga93f80feeef744. > > > > There are no regressions for C and C++ on x86_64-pc-linux-gnu. > > > > The new tests fail for the respective targets without this patch, and > > pass with it. > > > > PR rtl-optimization/122675 > > > > gcc/ChangeLog: > > > > * bb-reorder.cc (edge_order): Fix BB edge ordering to be > > descending. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/aarch64/pr122675-1.c: New test. > > * gcc.target/i386/pr122675-1.c: New test. > > * gcc.target/riscv/pr122675-1.c: New test. > So the comment for the function says we want to order with the highest > execution frequency first, this patch would seem to do the opposite. > > Similarly at the call site from within reorder_basic_blocks_simple, the > expectation is the most desirable (highest priority?) edges should be first. > > At the least I think updates to the comments are advisable. Explaining why > descending order is preferred seems highly advisable too. > > jeff > Hi Jeff,
I consider "descending order" and "highest execution frequency first" to be identical statements. I'll rephrase the comment and I'll send a new version to hopefully make it more clear. Regards, Dimitar
