https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> 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?
