> > By now we did CCP and FRE so we likely optimized out most of constant > > conditionals exposed by inline. > > So maybe we should simply delay re-propagation of the profile? I > think cunrolli doesn't so much care about the profile - cunrolli > is (was) about abstraction removal. Jump threading should be > the first pass to care.
That is what I was thinking too. After inlining the profile counts may be in quite bad shape. If you inline together loop like in exchange that has large loop nest, we will definitely end up capping counts to avoid overflow. cunrolli does: ret = tree_unroll_loops_completely (optimize >= 3, false); which sets may_increase_size to true for -O3 and then may_increase_size && optimize_loop_nest_for_speed_p (loop) which seems reasonable guard and it may get random answers on capped profile. It is not big deal to try propagating before cunrolli and then again before threading and see how much potential this idea has. I guess I should also double check that the other passes are indeed safe, but I think it is quite obvoius they should be. Honza > > Richard.
