https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> --- Hello, here is what happens. There is problematic block BB 36 ;; basic block 36, loop depth 0, count 34157, maybe hot ;; prev block 35, next block 37, flags: (HOT_PARTITION, RTL, MODIFIED) ;; pred: 33 [66.0% (guessed)] count:0 (CROSSING) ;; 35 [60.9%] count:34157 (FALLTHRU) ;; bb 36 artificial_defs: { } ;; bb 36 artificial_uses: { u-1(6){ }u-1(7){ }} ;; lr in 3 [bx] 4 [si] 6 [bp] 7 [sp] 20 [frame] ;; lr use 4 [si] 6 [bp] 7 [sp] ;; lr def 0 [ax] 5 [di] 17 [flags] ;; live in 3 [bx] 4 [si] 6 [bp] 7 [sp] 20 [frame] ;; live gen 0 [ax] 5 [di] 17 [flags] ;; live kill 17 [flags] (code_label 302 298 303 36 296 (nil) [1 uses]) (note 303 302 305 36 [bb 36] NOTE_INSN_BASIC_BLOCK) (insn 305 303 306 36 (set (reg/f:SI 0 ax [orig:870 _71->typed.type ] [870]) (mem/f/j:SI (plus:SI (reg/f:SI 4 si [orig:114 _71 ] [114]) (const_int 8 [0x8])) [0 _71->typed.type+0 S4 A32])) "../../gcc/tree-ssa-strlen.c":2727 75 {*movsi_internal} (nil)) (insn 306 305 8625 36 (set (reg:HI 5 di [orig:872 _7->base.code ] [872]) (mem/j:HI (reg/f:SI 0 ax [orig:870 _71->typed.type ] [870]) [0 _7->base.code+0 S2 A32])) "../../gcc/tree-ssa-strlen.c":2727 76 {*movhi_internal} (nil)) (insn 8625 306 308 36 (parallel [ (set (reg:SI 5 di [871]) (plus:SI (reg:SI 5 di [orig:872 _7->base.code ] [872]) (const_int -10 [0xfffffffffffffff6]))) (clobber (reg:CC 17 flags)) ]) "../../gcc/tree-ssa-strlen.c":2727 190 {*addsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (insn 308 8625 309 36 (set (reg:CC 17 flags) (compare:CC (reg:HI 5 di [871]) (const_int 1 [0x1]))) "../../gcc/tree-ssa-strlen.c":2727 6 {*cmphi_1} (expr_list:REG_DEAD (reg:HI 0 ax [871]) (nil))) (jump_insn 309 308 310 36 (set (pc) (if_then_else (gtu (reg:CC 17 flags) (const_int 0 [0])) (label_ref:SI 343) (pc))) "../../gcc/tree-ssa-strlen.c":2727 536 {*jcc} Now see it has two predecesors - one cold (count 0), BB 33 and one hot (BB 35)A Now BB 35 gets visited in trace 3 which is 31->32->35 BB 36 gets trace 9 (it is alone there) BB 33 gets trace 266 So we get Trace 3 (round 1): 31 [554] 32 [554] 35 [554] Trace 9 (round 2): 36 [337] Trace 266 (round 4): 33 [0] 34 [0] Now while connecting traces we get Connection: 912 819 Here it is processing trace 3 Connection: 45 31 Connection: 41 45 Connection: 37 38 Connection: 36 37 Here trace 9 gets used Connection: 35 36 changing bb of uid 8944 unscanned insn changing bb of uid 8939 unscanned insn scanning new insn with uid = 8939. changing bb of uid 8940 unscanned insn scanning new insn with uid = 8940. changing bb of uid 8941 unscanned insn scanning new insn with uid = 8941. changing bb of uid 8942 unscanned insn scanning new insn with uid = 8942. changing bb of uid 8943 unscanned insn scanning new insn with uid = 8943. Redirecting fallthru edge 35->36 to 913 Duplicated bb 36 (created bb 913) So BB 36 gets duplicated to be placed just after Trace 3. >From this moment BB 36 has only one cold predecestor and that is why fixup eventually turns it cold. The duplication happens because BB 36 is already attached to begining of the same trace so we are duplicating tail of the loop. This seems reasonable things to do. Only what BB reorder misses is that it may do the partitining fixup after the duplication. I am not sure if that is desirable as that would affect existing trace that may need to be updated, too. So still it seems reasonable to me to disable the partition fixup post bb-reorder because it only may trigger ICE if it suceeds so it is a waste of compile time. We may teach bb reorder to be bit smarter here, but it seems quite rare scenario.