[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #25 from Markus Trippelsdorf --- Ryzen is -march=znver1.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #24 from Eric Botcazou --- > Thanks. I can confirm it works for me! But it doesn't for me. What does -march=native expand to on your machine?
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #23 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #22) > (In reply to Martin Liška from comment #21) > > (In reply to Markus Trippelsdorf from comment #20) > > > Also happens on X86_64. I can reproduce the issue on gcc67 (Rzyen). > > > > Can you please provide revision and configure flags? Does it happen for the > > same source file? > > Current trunk and yes, it happens for the same source file. > > % ../gcc/configure --disable-libstdcxx-pch --disable-libvtv > --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp > --disable-werror --disable-multilib --enable-languages=c,c++,fortran > --enable-checking=release > > % make -j8 BOOT_CFLAGS="-march=native -O3 -pipe" > STAGE1_CFLAGS="-march=native -O3 -pipe" CFLAGS_FOR_TARGET="-march=native -O3 > -pipe" CXXFLAGS_FOR_TARGET="-march=native -O3 -pipe" profiledbootstrap Thanks. I can confirm it works for me!
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #22 from Markus Trippelsdorf --- (In reply to Martin Liška from comment #21) > (In reply to Markus Trippelsdorf from comment #20) > > Also happens on X86_64. I can reproduce the issue on gcc67 (Rzyen). > > Can you please provide revision and configure flags? Does it happen for the > same source file? Current trunk and yes, it happens for the same source file. % ../gcc/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++,fortran --enable-checking=release % make -j8 BOOT_CFLAGS="-march=native -O3 -pipe" STAGE1_CFLAGS="-march=native -O3 -pipe" CFLAGS_FOR_TARGET="-march=native -O3 -pipe" CXXFLAGS_FOR_TARGET="-march=native -O3 -pipe" profiledbootstrap
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #21 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #20) > Also happens on X86_64. I can reproduce the issue on gcc67 (Rzyen). Can you please provide revision and configure flags? Does it happen for the same source file?
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #20 from Markus Trippelsdorf --- Also happens on X86_64. I can reproduce the issue on gcc67 (Rzyen).
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #19 from Martin Liška --- Steps to reproduce: 1) create OBS account: https://build.opensuse.org 2) osc checkout home:marxin:gcc8-incubator-small2 3) cd home:marxin:gcc8-incubator-small2 4) osc build i586 One can easily add a patch to spec file for testing.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #18 from Martin Liška --- > The result is suboptimal though, since you end up with a (cold) block in the > hot partition whose only predecessors are in the cold partition. What > happens in this case if copy_bb_p returns false for the problematic block, > i.e. if you move the test I added lines 579-584 into the copy_bb_p predicate > itself? Does this result in a better reordered sequence of blocks? Can you please cook a patch for that which I can test?
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #17 from Jan Hubicka --- > > 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. > > The result is suboptimal though, since you end up with a (cold) block in the > hot partition whose only predecessors are in the cold partition. What happens > in this case if copy_bb_p returns false for the problematic block, i.e. if you > move the test I added lines 579-584 into the copy_bb_p predicate itself? Does > this result in a better reordered sequence of blocks? I have only dumps. Martin, would it be easy for you to rebuild it with the change? I would say that the duplication here is desriable optimization. Disabling it would only pesmize code in hot path that we don't want to do. So we would paper around missed optimization ICE by disabling another optimization. Right thing to do would be to move that BB into cold partition. In this case it won't be hard as it is not partitioned yet, so one would only need to check that partitioning fixes are OK. Other option may be to make partitining fixes to adjust the BB ordering. I.e. move all blocks promoted to be cold into beggining of cold section. That would still result in not completely optimal BB placement though. Honza
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Eric Botcazou --- > 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. OK, exactly the same sequence of events as: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02006.html > 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. The result is suboptimal though, since you end up with a (cold) block in the hot partition whose only predecessors are in the cold partition. What happens in this case if copy_bb_p returns false for the problematic block, i.e. if you move the test I added lines 579-584 into the copy_bb_p predicate itself? Does this result in a better reordered sequence of blocks?
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #15 from Jan Hubicka ---
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 in3 [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 kill17 [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 [0xfff6])))
(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.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #14 from Jan Hubicka --- > I cannot reproduce at r254648. How do you configure? I think it went away with the finish of counts conversion - the scenario trigerring the issue is very specific. I know what happens, but I am on a road right now. I will write it once reaching Czech Republic and wifi. Honza
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #13 from Eric Botcazou --- I cannot reproduce at r254648. How do you configure?
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #12 from Eric Botcazou --- > IMO turning random hot block into cold is not safe operatoin after > bbro is finished and thus Martin's patch preventing it is good. We can > indeed track down the real cause (I plan to iterate over profile updating > bugs > next week) We will never track the real cause if we paper over it...
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #11 from Eric Botcazou --- > I know you have some skill. Do you think problem is in traces how are traced > (more precisely why are the problematic blocks selected as hot)? > Or merging of the traces? I know it's problematic to reproduce as it happens > in profiled bootstrap, but I would appreciate any help ;) Yes, this could be during the connection of the traces, which involves copying basic blocks. When you do this, you redirect edges, which in turns changes the dominance relationship and thus can turn a hot block into a cold block.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #10 from Jan Hubicka --- > > No, I disagree, the patch only papers over the problem. > > > > > I wonder how we ended up with such contradictory block at the first > > > place? Was > > > it introduced by someone between the last expensive cfg cleanup and > > > bb-reorder? > > > > Yes, that's what needs to be investigated and probably fixed. > > Hi Eric. > > I'm also not happy about the patch. Can you please help me with the bbro pass. > I know you have some skill. Do you think problem is in traces how are traced > (more precisely why are the problematic blocks selected as hot)? > Or merging of the traces? I know it's problematic to reproduce as it happens > in > profiled bootstrap, but I would appreciate any help ;) Most likely the problem is insane profile before BBro itself. If it is indeed cfgcleanup with CLEANUP_EXPENSIVE needed to turn the basic block cold, I would say any pass between last invocation and bbro might have caused the pattern (possibly becuase the profile was nonsential even earlier). Grepping for it: bb-reorder.c: cfg_layout_initialize (CLEANUP_EXPENSIVE); bb-reorder.c: cleanup_cfg (CLEANUP_EXPENSIVE); bt-load.c:cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0); cfgcleanup.c: else if (mode & CLEANUP_EXPENSIVE) cfgcleanup.c: if ((mode & CLEANUP_EXPENSIVE) cfgcleanup.c: if ((mode & CLEANUP_EXPENSIVE) && !reload_completed cfgcleanup.c: cleanup_cfg ((optimize ? CLEANUP_EXPENSIVE : 0) function.c: cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0); ifcvt.c: cleanup_cfg (CLEANUP_EXPENSIVE); ira.c:cleanup_cfg (CLEANUP_EXPENSIVE); probably last cleanup was done by rest_of_handle_thread_prologue_and_epilogue and at that time cfgcleanup did not decided yet to do the move. IMO turning random hot block into cold is not safe operatoin after bbro is finished and thus Martin's patch preventing it is good. We can indeed track down the real cause (I plan to iterate over profile updating bugs next week) Honza
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #9 from Martin Liška --- (In reply to Eric Botcazou from comment #8) > > Thanks for working this out! The patch looks good to me. > > No, I disagree, the patch only papers over the problem. > > > I wonder how we ended up with such contradictory block at the first place? > > Was > > it introduced by someone between the last expensive cfg cleanup and > > bb-reorder? > > Yes, that's what needs to be investigated and probably fixed. Hi Eric. I'm also not happy about the patch. Can you please help me with the bbro pass. I know you have some skill. Do you think problem is in traces how are traced (more precisely why are the problematic blocks selected as hot)? Or merging of the traces? I know it's problematic to reproduce as it happens in profiled bootstrap, but I would appreciate any help ;)
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #8 from Eric Botcazou --- > Thanks for working this out! The patch looks good to me. No, I disagree, the patch only papers over the problem. > I wonder how we ended up with such contradictory block at the first place? > Was > it introduced by someone between the last expensive cfg cleanup and > bb-reorder? Yes, that's what needs to be investigated and probably fixed.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #7 from Martin Liška --- Created attachment 42581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42581=edit bbro rtl dump
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #6 from Martin Liška --- (In reply to Jan Hubicka from comment #5) > Thanks for working this out! The patch looks good to me. I wonder how we > ended up with such contradictory block at the first place? Was it introduced > by someone between the last expensive cfg cleanup and bb-reorder? > > Honza Good question. The BB (16 and 17) are marked first as hot in bb-reorder, later then identified by expensive cfg cleanup as cold. Feel free to investigate function body.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka --- Thanks for working this out! The patch looks good to me. I wonder how we ended up with such contradictory block at the first place? Was it introduced by someone between the last expensive cfg cleanup and bb-reorder? Honza
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #4 from Martin Liška ---
So problem is that in pass_reorder_blocks::execute we reorder blocks so that
they are separated to cold and hot partitions. Then cleanup_cfg
(CLEANUP_EXPENSIVE); is called (bb-reorder.c:2593) and we end here:
2324 static vec
2325 find_partition_fixes (bool flag_only)
2326 {
2327basic_block bb;
2328vec bbs_in_cold_partition = vNULL;
2329vec bbs_to_fix = vNULL;
2330hash_set set;
2331
2332/* Callers check this. */
2333gcc_checking_assert (crtl->has_bb_partition);
2334
2335find_bbs_reachable_by_hot_paths ();
2336
2337FOR_EACH_BB_FN (bb, cfun)
2338 if (!set.contains (bb)
2339 && BB_PARTITION (bb) != BB_COLD_PARTITION)
2340{
2341 if (flag_only)
2342error ("non-cold basic block %d reachable only "
2343 "by paths crossing the cold partition", bb->index);
2344 else
2345BB_SET_PARTITION (bb, BB_COLD_PARTITION);
2346 bbs_to_fix.safe_push (bb);
2347 bbs_in_cold_partition.safe_push (bb);
2348}
2349
2350return bbs_to_fix;
2351 }
and we mark one BB in hot partition as COLD. That causes the ICE.
What about something like this:
diff --git a/gcc/basic-block.h b/gcc/basic-block.h
index 5a5ddbfcb6d..5c393efd164 100644
--- a/gcc/basic-block.h
+++ b/gcc/basic-block.h
@@ -506,6 +506,7 @@ ei_cond (edge_iterator ei, edge *p)
insns. */
#define CLEANUP_CFGLAYOUT 32 /* Do cleanup in cfglayout mode. */
#define CLEANUP_CFG_CHANGED64 /* The caller changed the CFG. */
+#define CLEANUP_NO_PARTITIONING128 /* Do not try to fix
partitions. */
/* Return true if BB is in a transaction. */
diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index f7c1f4c971e..20e231739e3 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -2590,7 +2590,7 @@ pass_reorder_blocks::execute (function *fun)
cfg_layout_initialize (CLEANUP_EXPENSIVE);
reorder_basic_blocks ();
- cleanup_cfg (CLEANUP_EXPENSIVE);
+ cleanup_cfg (CLEANUP_EXPENSIVE | CLEANUP_NO_PARTITIONING);
FOR_EACH_BB_FN (bb, fun)
if (bb->next_bb != EXIT_BLOCK_PTR_FOR_FN (fun))
diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 4734d3eae17..84756a542da 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -3011,7 +3011,8 @@ try_optimize_cfg (int mode)
to detect and fix during edge forwarding, and in some cases
is only visible after newly unreachable blocks are deleted,
which will be done in fixup_partitions. */
- fixup_partitions ();
+ if ((mode & CLEANUP_NO_PARTITIONING) == 0)
+ fixup_partitions ();
checking_verify_flow_info ();
}
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #3 from Martin Liška ---
The problematic block (for which we trigger the assert is):
(gdb) p debug_bb(bb)
(code_label 8952 8954 310 18 1247 (nil) [2 uses])
(note 310 8952 311 18 [bb 18] NOTE_INSN_BASIC_BLOCK)
(insn:TI 311 310 313 18 (set (reg/f:SI 0 ax [orig:873 MEM[(struct phi_arg_d
*)gsi_240].args[0].def ] [873])
(mem/f:SI (plus:SI (reg/f:SI 3 bx [orig:127 gsi ] [127])
(const_int 56 [0x38])) [193 MEM[(struct phi_arg_d
*)gsi_240].args[0].def+0 S4 A32])) "../../gcc/tree-ssa-strlen.c":2729 75
{*movsi_internal}
(nil))
(call_insn:TI 313 311 315 18 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("_ZL10get_stridxP9tree_node") [flags 0x3]
) [0 get_stridx S1 A8])
(const_int 0 [0]))) "../../gcc/tree-ssa-strlen.c":2729 553
{*call_value}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("_ZL10get_stridxP9tree_node")
[flags 0x3] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:SI (use (reg:SI 0 ax))
(nil)))
(insn:TI 315 313 314 18 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [orig:110 idx ] [110])
(const_int 0 [0]))) "../../gcc/tree-ssa-strlen.c":2730 3
{*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 0 ax [orig:110 idx ] [110])
(nil)))
(insn 314 315 316 18 (set (reg/v:SI 5 di [orig:110 idx ] [110])
(reg:SI 0 ax)) "../../gcc/tree-ssa-strlen.c":2729 75 {*movsi_internal}
(nil))
(jump_insn:TI 316 314 317 18 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:SI 343)
(pc))) "../../gcc/tree-ssa-strlen.c":2730 536 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 1064185877 (nil)))
-> 343)
Has following count:
(gdb) p bb->count
$10 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 9888, m_quality =
profile_precise}
And previous block is:
(gdb) p bb->prev_bb
$11 = (basic_block) 0xf3afc3c0
(gdb) p debug_bb(bb->prev_bb)
(note 8951 309 8953 17 [bb 17] NOTE_INSN_BASIC_BLOCK)
(jump_insn/j:TI 8953 8951 8954 17 (set (pc)
(label_ref 8952)) 537 {jump}
(nil)
-> 8952)
Has count:
(gdb) p bb->prev_bb.count
$13 = {static n_bits = 61, static max_count = 2305843009213693950, static
uninitialized_count = 2305843009213693951, m_val = 0, m_quality =
profile_precise}
And the count is set here:
#0 0x084bce69 in force_nonfallthru_and_redirect (e=0xf4247400,
target=0xf3fd4438, jump_label=0x0) at ../../gcc/cfgrtl.c:1631
#1 0x084bd902 in rtl_force_nonfallthru (e=0xf4247400) at
../../gcc/cfgrtl.c:1709
#2 0x084ac2a4 in force_nonfallthru(edge_def*) ()
#3 0x084c1257 in fixup_new_cold_bb (bb=0xf4233c6c) at ../../gcc/cfgrtl.c:1394
#4 fixup_partitions () at ../../gcc/cfgrtl.c:2384
#5 0x08d688e5 in cleanup_cfg(int) ()
#6 0x08d54afb in (anonymous namespace)::pass_reorder_blocks::execute
(this=0x9938470, fun=0xf47733a8) at ../../gcc/bb-reorder.c:2593
#7 0x0873d5aa in execute_one_pass(opt_pass*) ()
#8 0x0873ddbf in execute_pass_list_1(opt_pass*) ()
#9 0x0873ddd2 in execute_pass_list_1(opt_pass*) ()
#10 0x0873ddd2 in execute_pass_list_1(opt_pass*) ()
#11 0x0873de19 in execute_pass_list(function*, opt_pass*) ()
#12 0x084d547c in cgraph_node::expand() ()
#13 0x084d65ba in symbol_table::compile() [clone .part.55] ()
#14 0x084d8389 in symbol_table::finalize_compilation_unit() ()
#15 0x087f613e in compile_file() ()
#16 0x082c03b9 in toplev::main(int, char**) ()
#17 0x082c2781 in main ()
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-07 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > This seems previously latent bug in bb-reorder. It produces order of blocks > which has hot blocks, then some cold blocks and then hot blocks again. Probably because some hot block is turned into a cold block, see: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02006.html for a previous example.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #1 from Jan Hubicka --- This seems previously latent bug in bb-reorder. It produces order of blocks which has hot blocks, then some cold blocks and then hot blocks again. I am not sure why this happens though. Honza
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
