> 
> 
> On 12/4/25 10:18 AM, Dimitar Dimitrov wrote:
> > On Thu, Dec 04, 2025 at 03:27:53PM +0100, Jan Hubicka 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.
> > > 
> > > This is OK.
> > > Thanks for cathing this and sorry for late reply - I was organizing a 
> > > workshop.
> > > 
> > > Honza
> > 
> > Thank you Honza. Could you please confirm that you prefer this version,
> > and not the latter [V3] where I addressed Jeff's concerns?
> Given Honza knows this code *far* better than I, if he's OK, then don't
> worry about any of my concerns.
Sorry, I did not see the other message in the thread (was still in
process of cathing up with email after the meeting).

V3 version is also good (though the low_to_high temporary seems bit
redundant, but if it improves clarity, why not).  I always have to think
twice with qsort comparators and have tendency to systematically reverse
them...

The patched behaviour seems to be right one - highest frequency first.
The pass uses the sorted sqauences to walk edges and attempts connect
sequences of blocks along their endpoints. We want to connect over high
frequency edges.

Honza
> 
> jeff

Reply via email to