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.
