https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831
--- Comment #17 from Jan Hubicka <hubicka at ucw dot cz> --- > > 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
