> Hi! > > This patch doesn't fix the actual bug somewhere else, where inserting > stmts on the edge between resx and corresponding landing pad confuses > ehcleanup2, but attempts to restore previous behavior in the heuristics, > which is IMHO desirable too (and makes the bug latent). > r254698 changed: > if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb) > - && best_bb->count.to_frequency (cfun) > - < (early_bb->count.to_frequency (cfun) * threshold / 100.0)) > + /* If result of comparsion is unknown, preffer EARLY_BB. > + Thus use !(...>=..) rather than (...<...) */ > + && !(best_bb->count.apply_scale (100, 1) > + > (early_bb->count.apply_scale (threshold, 1)))) > return best_bb; > I understand the difference between x < y and !(x >= y), profile_count > comparisons are partial ordering, but the old x < y corresponds to > !(x >= y) as the comment says, not to !(x > y) as the patch implemented. > On the testcase, we have > something; > resx 4; > and the count on the resx 4; bb is already zero, it is already something > invoked after first throw, there is no advantage to sink statements across > the resx 4; to the fallthru (across EH edge) bb, because both bbs will be > executed exactly the same times. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-11-21 Jakub Jelinek <ja...@redhat.com> > > PR tree-optimization/91355 > * tree-ssa-sink.c (select_best_block): Use >= rather than > > for early_bb scaled count with best_bb count comparison. > > * g++.dg/torture/pr91355.C: New test.
This is OK, thanks! Honza
