https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127420
--- Comment #4 from Haochen Jiang <haochen.jiang at intel dot com> --- (In reply to Hongtao Liu from comment #3) > (In reply to Richard Biener from comment #2) > > With profile information (autofdo lbr) we might know the most likely target, > > we also know whether this is a computed goto which is the only case where we > > can easily re-order blocks to have the destination follow the branch. In > > the > > computed goto case we should have an abnormal edge to it, possibly annotated > > with a frequency. > > > > I wonder if we can measure how many cases we slow down by emitting UD2? > > Interesting, we can do some investigation with SPEC to see how many indirect > jump target it's fallthru instruction. Assisted by AI, I tried with taking samples for SPEC run to see how many of them. The ratio compiler generated indirect jump actually turning out to be "FALLTHRU" effect sampled versus compiler generated indirect jump. For SPEC2017, it is about 7.77%. For SPEC2026, it is 2.91%. But it varies a lot between benchmarks. The largest benchmarks based on ratio is 735.gem5_r and 734.vpr_r, with 26.70% and 23.47%. All >5% benchmarks are shown below: | Benchmark | Indirect jumps sampled | Fall-through hits | Fall-through rate = hits / all | 735.gem5_r | 3,537,621 | 944,409 | **26.696 %** | 734.vpr_r | 495,073 | 116,183 | **23.468 %** | 511.povray_r | 14,135,966 | 2,692,956 | **19.050 %** | 736.ocio_r | 7,636 | 1,395 | **18.269 %** | 731.astcenc_r | 724,535 | 84,497 | **11.662 %** | 753.ns3_r | 579,529 | 57,184 | **9.867 %** | 502.gcc_r | 6,487,386 | 578,975 | **8.925 %** | 723.llvm_r | 6,832,549 | 487,575 | **7.136 %** | 721.gcc_r | 6,174,523 | 425,833 | **6.897 %** | 525.x264_r | 3,316,792 | 225,741 | **6.806 %** | 557.xz_r | 6,421,731 | 378,953 | **5.901 %** I have not test the perf affect on the patch yet. But it might be an issue to insert them everywhere.
