https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527
--- Comment #4 from Di Zhao <dizhao at os dot amperecomputing.com> --- The problem is found in 548.exchange2 of SPEC2017. As the profile counts are not adjusted after PRE, bbro produced sub-optimized order of basic blocks. In my test results on x86 (i0-10700) and aarch64 (Graviton), with the above change in sccvn, there is about 1% improvement in 548.exchange2. I think when sccvn finds a loop won't iterate, it replaces a guessed iteration count with a known count (=1). So although there are chances that the profile counts for extra exits are still wrong, considering other optimizations like bbro, it is still beneficial than harmful?
