https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I think we have two issues. One is that if we sink something on the edge between resx and corresponding landing pad, ehcleanup2 is upset, and the other one is that it is really not beneficial to sink the stmts there. If we fix the latter, we'd just have a latent bug though. In the testcase, both best_bb (the bb from splitting the EH edge) as well as early_bb have count of 0, because this is all EH stuff and happens only if the code throws (which is always, but we handle EH as something very rare). r254698 changed best_bb->count.to_frequency < early_bb->count.to_frequency * 82% to !(best_bb->count.apply_scale(100,1) > early_bb->count.apply_scale(82,1)) and so with zero counts the condition was false, but now it is true. Though, the comment talks about !(... >= ...) rather than !(... > ...). Honza, shouldn't that be !(... >= ...) as the comment says? At least for the case of zero counts, if early_bb has the same count as best_bb, it isn't profitable to sink it, it should be profitable only if it has 82% smaller count (or smaller). Changing the > into >= makes the wrong-code go away, though as I said, we have a latent issue and from what I understood, PRE might be inserting on such edges too, otherwise we wouldn't split it.
